I would say maybe something like cabal add <dependency> <target-package> would suffice. If there’s only one package, just send it there by default.
I dont really know what cabal expand-bounds would do 
… But I don’t know much about cabal files besides how to add dependencies, expose modules, and I just recently learned how to set default language extensions 
Well, Cabal has a notion of targets, such as some-package:exe:some-executable. (Even though it is not communicated to the users as clearly as I should wish — for example, there is no way to list all available targets in the current project.) So, there is already a syntax for telling Cabal where you want to add that dependency.
The hard problem is to get an exact parser-printer pair for Cabal — as I understand, Emily @emilypi championed this project a year ago or so but it eventually stalled. And without an exact parser-printer pair we cannot programmatically add or remove anything.
The exact-print parser is coming. 
As I understand (or project) your idea for the cabal add command, it would be as simple as possible so the beginners with trivial projects and packages don’t need to go into the weeds of what’s possible. Another requirement would be that the resulting bounds are PVP-compliant. The intersection of these two requirements means that the command cabal add my-new-dependency would just add something like , my-new-dependency ^>= X.Y.Z where X.Y.Z is the latest version of the dependency in Hackage index. The command should probably also verify that the bounds of my-new-dependency-X.Y.Z bounds are compatible with the bounds of all the existing dependencies, but that’s as far as I’d have it go.
That’s for beginners. Once those beginners gain some experience, they’ll notice that the automatically-added dependency bounds are too restrictive. Expanding those bounds is a far more demanding task with more knobs and a different user base. That’s why I’m suggesting it should be a separate Cabal command rather than a set of options on cabal add.
Ah I see, yea that makes sense, and I agree. The cabal add command is for the beginners, or for people who just wanna go fast; It shouldn’t have to do anything more than just pick the latest version (or the latest version that works). It would be cool if it was capable of figuring out the widest possible version bounds, but that’s probably outside the scope of such a tool
Slowed, not stalled - it needed a person who wanted to see it through to the end and sadly, I became busy with life. Leave it to @Kleidukos and the more active team members and we’ll have one soon enough.
Heyo!
Our HSoC participant @VeryMilkyJoe is working on a POC for Feature Request: Add current file to Cabal (exposed/other) modules · Issue #3595 · haskell/haskell-language-server · GitHub. In the context of that work, a third-party Cabal parser is currently being written, that hopes to become an exact printer in the future. We don’t want to promise too much at this point, though.
Stay tuned for updates and the next HLS release
Also remove-bounds!
Currently I have some hacky shell scripts in ghc-rpm-macros for packaging:
Has anyone said cabal-hoogle already?
A command that opens a local hoogle server for a project.
That would be rad, especially with cabal haddock-project!
there is stack hoogle --server which is fantastic. A cabal equivalent would be as good !
Looks like the program actually already exists: cabal-hoogle: generate hoogle database for cabal project and dependencies
cabal-plan also fits here, although it seems to already work (not needing an amended environment).
As @fgaz suggested in a PR review, it would be nice to maintain a list of existing plugins, and perhaps ideas for new ones, and maybe we need a more permanent solution than a discourse thread. How about a page on the Cabal wiki or a simple document in the Cabal repository? Suggestions are welcome
I miss a cabal subcommand to print targets in the current package or project. E.g., cabal list-targets.
I’m very excited for this functionality. It will serve as a nice buffer similar to GHC plugins.
When people have a feature request, they can just be told “this could be a cabal plugin - how about you prove it out that way first?”
I think this sort of thing is especially useful for Haskell since it has way less monolithic/homogenous of a user base than other languages. It prevents dogpiling onto the mainline tools, and it prevents more influential/powerful factions (e.g. industrial interests) from completely driving things in their preferred way.
to throw a couple out there, cabal watch to basically do what ghcid does, and cabal deploy that might be quite ambitious but it would be a killer feature.
By cabal deploy do mean “deploy to Hackage”? Would it be a combination of cabal sdist and cabal upload with appropriate flags?
No it’s about deploying an application to a PaaS provider like Heroku, Fly.io or the likes of it
Yes exactly, that’d be dope!
I guess what we’re getting at is to support a more general command, something similar in spirit to npm run <task>, maybe cabal do <task>? then the task can do whatever, I could imagine the tasks to be listed in the cabal.project, perhaps with shake support, so that any shake rule/phony is one of these tasks or, of course, allow the user to specify any IO () as a task.