stackage-sandbox

[DanBurton]

A tool to assist in using cabal sandbox with stackage. Provides init, delete and upgrade subcommands which should safely replace their stackage counterparts. It also provides a verify subcommand to make sure that everything installed in the sandbox matches the constraints in cabal.config.

Overall, it should feel like the same workflow, just enhanced with automagical sandbox sharing.

stackage sandbox init [SNAPSHOT]

• Does cabal.sandbox.config exist?
  • yes: warn & do nothing (exit failure)
• Does cabal.config exist?
  • no: run stackage init [SNAPSHOT]. (Now cabal.config exists.)
  • yes:
    • Parse cabal.config and figure out which snapshot it is
      • fail if it doesn't look like a config file downloaded from stackage.org
• Was a snapshot argument provided?
  • no: use the snapshot version from cabal.config
  • yes: warn & do nothing if it doesn't match the version in cabal.config
• Create $HOME/.stackage if it doesn't exist
• Create $HOME/.stackage/sandboxes if it doesn't exist
• Create $HOME/.stackage/sandboxes/ghc-x.y.z if it doesn't exist, based on ghc --version
• Create $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT if it doesn't exist, based on the snapshot we've decided on by now
• Do a cabal sandbox init --sandbox $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT
  • this will init the sandbox at that location, or reuse it if already init'd
• Perform stackage sandbox verify
  • take appropriate action if it doesn't pass verification

stackage sandbox delete [SNAPSHOT]

This is a different notion than stackage purge, so I think it should be named differently.

If no snapshot is provided, this simply means "delete my config files."

• delete cabal.sandbox.config
• delete cabal.config

If a snapshot is provided, this simply means "delete that sandbox."

• recursively delete $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT
  -- maybe this should be a differently-named command.

stackage sandbox upgrade [SNAPSHOT]

• Is SNAPSHOT the same as the cabal.config and current sandbox?
  • inform & do nothing (exit success)
• stackage sandbox delete
• stackage sandbox init [SNAPSHOT]

stackage sandbox verify [SNAPSHOT]

If no snapshot is provided, this means "verify this project's use of a sandbox"

• Determine the current snapshot from cabal.config
• Make sure this matches the expected sandbox directory
• ghc-pkg list, make sure versions match the cabal.config constraints

If snapshot is provided, this means "verify this snapshot" regardless of current directory.

• download the corresponding cabal.config to a temp file
• ghc-pkg list, make sure versions match the cabal.config constraints

The verify command has potential to do more careful verification, but I think this is a good start.

stackage sandbox fork

A nice-to-have, this would copy the shared sandbox, so that non-snapshot-adhering installs can be made without ruining the shared sandbox. Here's a relevant thread for how to accomplish this:

http://permalink.gmane.org/gmane.comp.lang.haskell.cafe/115691

[chrisdone]

This is a really nice outline. It's very clear. Comments:

• One small worry is how to make sure every project within a particular sandbox's scope has the proper cabal.config constraints. It's acceptable that the user just has to run the command in all directories when doing an upgrade or whatnot, but a potential way to nip this in the bud could be to put all the cabal.config constraints in the cabal.sandbox.config. I'm 50% sure this is possible, but with the caveat that the format differs ever so slightly (pointlessly, probably). (@snoyberg?) With this in place, you could just reject any project that has a cabal.config file complaining that it's incompatible with "sandbox mode" or w/e. Although verify below may be a way around this issue.

• Is the $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT format including ghc version is to avoid conflicts? If so, stackage snapshots are GHC-specific anyway. OTOH it costs nothing to have this and it could avoid any unforeseen stuff so it seems like a good idea anyway.

• If a snapshot is provided, this simply means "delete that sandbox." recursively delete $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT -- maybe this should be a differently-named command.

  This particular behaviour is more like purge, probably.

• The upgrade behavior implies only a directory local action… so that this will actually end up with sandbox A and sandbox B for different snapshot versions, with this directory on the new snapshot, but other directories still pointing to the old. This seems okay if we make sure to note in the output that the old sandbox still exists and that you can still use it (e.g. and even switch back, which can be nice), and that if you want to clear up the disk space you can use the delete/purge command. Like a git gc.

• I like the verify idea. This can be a way to mitigate some of the earlier concerns. Probably its position in this list is good for indicating its priority with respect to the others.

• Forking would be nice indeed, I'd put this in as a side-item with lower prio than the others. On the surface the naive copy & sed approach sounds plausible although it doesn't take into account things like Paths_foo and such which are hard-coded into libraries and binaries. So let's put this in a "to look into" side issue.

Please make an issue for each of these (just copying over your content from here). Then we can close this issue. The init command can be the first thing to tackle as having that done gives us 90% of the value in this tool. We want to open source stackage-cli this week, so I'll make an issue tracking any cleanup/docs/finishing touches (including a README) for the general public which should probably come first, lest other priorities block work on stackage-cli before we get to releasing. Then sandboxes can be implemented.

[DanBurton]

Created issues #9, #10, #11, #12, and #13 out of this one.

[chrisdone]

Cool. Any comments on my comments?

[DanBurton]

Not particularly. I think we're generally on the same page.

put all the cabal.config constraints in the cabal.sandbox.config. I'm 50% sure this is possible, but with the caveat that the format differs ever so slightly

I tried at one point to do a copy/paste from cabal.config to cabal.sandbox.config and was disappointed that it didn't work. I agree that if something like this is possible, then this is the way to go.

Is the $HOME/.stackage/sandboxes/ghc-x.y.z/SNAPSHOT format including ghc version is to avoid conflicts?

Your thought process is the same as mine. After I wrote that section, I reflected and realized it was probably unnecessary, but also harmless and potentially still useful.

This seems okay if we make sure to note in the output that the old sandbox still exists and that you can still use it

Agreed. I added a comment to #11 to remember this.

[chrisdone]

Cool, we can proceed in the other issues then.