Add commands for automating stack.yaml management

[snoyberg]

Originally discussed in #27. Exact requirements here are uncertain, some ideas:

• Upgrade to a new snapshot
• Prune the extra-deps
• Add an extra package to the list of packages (and remove one?)
• Use a dependency solver to automatically add necessary extra-deps

[chrisdone]

Jotting down ideas:

Possibly can implement this like git config, e.g.

• stack config add packages foo/
• stack config add extra-deps monad-unlift-0.1.1.0
• stack config set resolver lts-2.9
• stack config get resolver => lts-2.9

(add would assume an array, set would assume an atomic value, either would parse a yaml "expression", get would pretty print whatever yaml is there.)

For a generic interface. These are particularly handy for easy scripting or IDE use.
Then you could have specialized commands like stack upgrade lts-2.10 that do something more than just editing the file, and prune, etc.

[gregwebs]

personally I would probably just edit the YAML file for some of these, particularly if there is good feedback about incorrect configurations of the YAML file.

[chrisdone]

Part of the motivation here is to keep the config machine-readable and machine-writable, especially as it'll probably expand in scope. Automatic edits to cabal files is a PITA for IDEs (and Emacs) to do because user-edits were prioritized over machine edits. Comparatively, tooling for Git is easy because the information is always easy to read and edit by tools. Hence, I propose we take the Git approach in which commandline edit (or read) or manual edit is possible.

But yeah, there should also be decent error messages from the YAML parser, agreed.

[chrisdone]

(That and it's nice to give newbies a line like git remote add x and be done with it, rather than "okay, open your .git/config and find the section...")

[gregwebs]

makes sense that it is much easier for tooling. Otherwise tooling would need to depend on a yaml lib and the YAML format would be an interface that is more difficult to change.

[chreekat]

+1 for easy way to upgrade snapshot (and probably extra-deps at the same time). Looks like the current way to do it is

• move stack.yaml
• (re)run stack build/init (if/when init exists) — which should not fare very well
• see if any extra-deps have made it into the new snapshot
• manually check the extra-deps to see if any newer versions are available
• merge the old stack.yaml into the new one

Lots of hairballs there.

[rvion]

+1, I find myself doing naively the same as @chreekat for now