[Haskell-cafe] cabal v2 global install status

[Ivan Perez]

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 <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


On Wed, 4 May 2022 at 13:15, Richard Eisenberg <lists at richarde.dev> 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20220505/1ec55070/attachment.html>