Re: [Haskell-cafe] cabal v2 global install status

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: Properties.hs:2:1: error: Ambiguous module name ‘Language.Copilot’: it was found in multiple packages: copilot-3.5 copilot-3.5 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 cabal v1-exec -- ghci -hide-package 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 On Wed, 4 May 2022 at 13:15, Richard Eisenberg wrote:

I have found that cabal v2-install --lib has not worked for me in this use case.

Instead, I use https://github.com/phadej/cabal-extras/tree/master/cabal-env, which despite being somewhat old at this point, works beautifully for the use-case Tom describes.

Richard

On May 4, 2022, at 12:56 PM, amindfv--- via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

On Wed, May 04, 2022 at 06:42:53PM +0200, Francesco Ariis wrote:

Il 04 maggio 2022 alle 09:31 amindfv--- via Haskell-Cafe ha scritto:

I'm very comfortable using cabal's `v2-` nix-style local builds at home and at work, but on a personal machine at home I've clung to `v1-install` because I _really_ like the ability to choose which packages are available in a simple `ghci` session.

For a long time that's been impossible or painful with the `v2-` commands. What's the status these days? I'm particularly interested in how it works for packages that only exist locally without a Hackage server.

Does

cabal new-install --lib

do what you want?

I don't know; in the past it hasn't, and I wanted to see what the current recommendations are before going down a long and potentially incorrect path.

Cheers, Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.