Alternative technique for mixing

[istathar]

I was about to write a tool almost exactly like sandman. I see you've already done it! Nice work.

One suggestion to consider: in my research leading up to starting to write my own code, I learned a bit more about how ghc-pkg(1) manages things. We sort of know this implicitly because we see it happening when we we do ghc-pkg list but indeed there can be multiple package databases, and they are taken in order off of the GHC_PACKAGE_PATH environment variable (in the absence of equivalent -package-db declarations on the ghc(1) command line). That means rather than copying into a local build's sandbox's package.conf.d tree, you could perhaps instead leave them in place in your ~/.sandman/sandboxes/{name}/ tree.

I assume that doesn't add up to anything because you're supporting people then going back to using the existing cabal(1) front end. But if you go the the next level, and start thinking about a replacement for 'cabal-install' then you could indeed control the environment or arguments to ghc and do mixing a different way.

... if that gets you anything.

AfC

[abhinav]

My understanding was that you couldn't use GHC_PACKAGE_PATH with cabal. It spits the following error for me with cabal-install 1.20.0.5 and Cabal 1.20.0.3:

Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal. Use the flag --package-db to specify a package database (it can be used multiple times).

Supplying -package-db all the time (as suggested by the error message) is unreasonable unless we control the calsl to GHC or wrap at least the ghc, ghc-pkg, and ghci commands to add the flag automatically; which sounds like another can of worms.

Additionally, and this is a minor usability nit: If you're using the environment variable to inject the extra package DB, then you will need to do something similar to sandman activate in every terminal you're using to work on your project. The current solution has the advantage of allowing you to simply cd into the project directory and start working at it. It works seamlessly with tools like ghc-mod, codex, etc.

That is not to say I'm opposed to using the environment variable approach. I'll definitely look into switching if a major advantage arises.

Lastly, I did not intend to replace cabal-install but to augment it. Cabal does its job really well and duplicating all that effort in yet another tool seems unnecessary. The primary concern was reducing the amount of time spent rebuilding the same common packages and to make ad-hoc temporary sandboxes more convenient*. Cabal may possibly solve that natively in the future and obsolete sandman (haskell/cabal#2365).

---

*When I want to write small scripts of a throwaway nature, setting up a sandboxed Cabal project and/or re-building the same dependencies over and over is too much. With sandman I have streamlined my process for this to:

mkdir tmp && cd tmp
cabal sandbox init
sandman mix common  # optionally with a list of explicit dependencies using -o
vim someScript.hs
ghc -package-db .cabal-sandbox/*.conf.d someScript.hs  # this could be provided by a "ghc" command

ghc-mod is able to work with raw Cabal sandboxes without a .cabal file, so I get all the usual goodies too!

[istathar]

One other specific question: have you dealt with the requirement that @edsko described about making sandboxes immutable once a fork/clone is made?

[istathar]

ghc -package-db .cabal-sandbox/*.conf.d someScript.hs

I do that via

$ cabal exec ghci someScript.hs

which seems to do the trick. Is that wrong?

AfC

[abhinav]

Immutable sandboxes sounds interesting. Does that mean I wouldn't be able to install another package into my existing common package?

Oh, wow, I did not realize cabal exec would work without a .cabal file. Thanks!

[istathar]

@abhinav I think it's ok? From http://www.edsko.net/2015/03/09/sandboxes-revisited/,

Note that if you do things this way, you should regard the shared sandbox as immutable, much like the global package DB. It’s okay to add packages to it, but as soon as you rebuild any of the packages in it (or even remove them) all derived sandboxes will break.

which seems to be the way you're leaning already.

When I was talking about wanting to redo the tooling, it's things like this: a sandbox (sic) should be forked automatically when an upgrade is required. Which of course is where Nix shines. Like you, I'd like to see if we can solve this within the existing machinery ghc-pkg and 'Cabal' provide.

Anyway, it seems like @edsko has rewritten the sandbox rulebook somewhat. I just wanted to make sure you'd noticed that part about sharing vs forking.

Cheers!

AfC