Add missing cabal functionality to stack

[snoyberg]

After we've addressed our basic use cases, we should run through all of the commands that cabal supports and see which ones we want to port. For example, I can imagine wanting to run stack unpack.

[DanBurton]

Given the default behavior of stack will be to use a (cabal?) sandbox, do we want to provide things like stack sandbox add-source to work with that sandbox? And would this actually make calls to cabal, or write things to stack.yaml instead?

[snoyberg]

We won't be using cabal sandboxes, just custom package databases. Which is essentially the same as a cabal sandbox, the only reasons cabal sandboxes are this super complicated thing are:

1. cabal lacks proper multi-package support
2. cabal goes out of its way to impair GHC's abilities to support multiple package databases (the GHC_PACKAGE_PATH variable)

Adding a source should just be modifying the stack.yaml file. I'm a bit ambivalent as to whether we should have a command to do that. I think the points in favor of obvious (feature parity/ease of use). The point against is that rewriting a YAML file almost certainly will lose formatting and comments (I've experienced this personally with the Travis command line tool).

[chrisdone]

I think .git/config could be considered comparable. Some git tools (like git remote add …) will rewrite your config file, and sometimes you manually edit your config file. You could consider it ideal that you only rarely edit your config file manually, like git. In which case preserving formatting and comments is less of a priority.

[snoyberg]

Except that, in this case, stack.yaml will be checked into version control and shared among multiple people, so it's much more likely that people will put explanatory comments in there.

[snoyberg]

Discussed a bit more on Slack, we decided to go with the automation since:

• in any case being in version control means it matters less if a tool munges your content because you can just undo it
• i guess it's a choice of what we want to encourage. cabal started out as machine readable/writable format but in fact encourages meaningful user formatting and comments anyway, with no commands that i can recall that actually update a cabal file, so that goal was lost. if we want to have our tool save the user work then that's the trade-off
• once you start with "but what about user formatting" the book seems to be closed on automation
• users can always use the tool, see the output, git reset --hard and apply it manually

[snoyberg]

It looks like the only thing left to be done here is "provide some commands for managing the config file." If this is accurate, I think we should close this issue and open a new one about a config-management command, as this title is overly broad for that purpose.

[chrisdone]

Agreed.

[snoyberg]

Closing in favor of #115