I concur with Tom's feeling and the fact that v2-install --lib has not always worked well for me. I kept around this error message from one of my sessions about 1/2y ago:
I spent hours and never figured out 1) what was going on or 2) how to select which copilot version I meant... :S
The v1-style and, in particular, v1-sandbox, v1-install, and v1-exec, were great and, when combined, afforded the flexibility you were mentioning. The fact that they executed in a local environment, leaving everything else on the machine unaffected, and with all packages in the sandbox enabled in ghci/ghc by default, was intuitive and pleasant to work with.
This made my job as a dev and maintainer so much easier. I've routinely worked with very large packages (some take 1h or more to compile). Being able to completely remove packages pertaining to one project (rm .cabal-sandbox) leaving everything else unaffected --just by virtue of the fact that that's where things were stored-- was an absolute game changer. Being able to run ghc/ghci on a package compiled with specific flags or changes, and knowing I was picking the right version just because of the location i was running ghci in, was incredibly simple to work with.
It made installation of Haskell packages for newbies easier too:
create a sandbox. mess around in it, and if you want to start over, just
erase .cabal-sandbox. Done! All your other projects remain unaffected.
There's no need to use advanced cabal commands or learn about how cabal
chooses to store things in $HOME/.cabal.
I know it may sound like a bit of a detour from your original
request, but I think it isn't. If we had this back, we could have steps close to the old:
cabal v1-sandbox init
cabal v1-install <packages_in_current_dir_maybe>
cabal v1-exec -- ghci -hide-package <I_dont_want_this_specific_package_but_everything_else>
which would give you the flexibility you were asking for. (sandboxes also had `v1-sandbox add-source` so you could let the sandbox know where to pick packages in your local drive from.)
Cabal v2 has some --store argument to keep things local. It doesn't always work as expected (especially when installing tools), but I think it's because it has not been used as much. This workflow (installing packages in a store in the project directory) should be not just supported, but encouraged. Keeping all changes local should be the default. Experts, and those who want to optimize installation times, avoid re-compilation, those who know how to navigate $HOME/.cabal if need be, etc., can then choose to share that installation directory across projects and use $HOME/.cabal instead (or whatever else they want). But that's a conscious choice made by an expert who understands the choice.
If we keep things local with --store, all we'd need is a way to run (v2-exec) ghc/ghci/whatever with all packages in the current environment available/enabled and you'd be very close to what you were asking for.
Ivan