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

[snoyberg]

Following #390: running stack config set resolver nightly should set to the newest nightly. Other similar kinds of shortcuts should be allowed too (e.g., lts-2 for newest LTS 2.x).

[alanz]

Would stack config set resolver nightly update the per-project config or the global (on a given machine) config?

Because if the latter, it makes it simple to move a given dev environment as a whole onto a different snapshot/nightly.

[snoyberg]

I think it would do both: stack config should work the same way as stack exec/stack ghci, using a local project config if available, otherwise falling back to the default global (aka ExecStrategy in the code base). Thanks for pointing out this requirement.

[ekmett]

👍 I just found myself in the situation of needing some form of stack config set resolver nightly that doesn't involve a hack that goes and retrieves the current version from the json document and found my way to this ticket.

[drwebb]

stack config set resolver <snapshot> is currently in master. There is another branch where I am adding stack config add extra-dep <packagename>-packagever [--suggested]. It would be great to have more generic add and sets, but it's easier to just add in special cases for the %80 of actual uses.

[harendra-kumar]

Something that may be relevant to this discussion - augeas is a nice tool to manipulate config files in a generic way. One can write a augeas lens for stack.yaml to be able to manipulate it via augtool. This can be handy to manipulate stack.yaml through scripts. I could find one example of a YAML lens on my debian jessie linux installation - /usr/share/augeas/lenses/dist/cobblersettings.aug. May be a good idea to adapt that to stack.aug if anyone is interested.

If we ship the lens with augeas then it will provide anyone the ability to manipulate stack configs via standard configuration management tools which support augeas. Not sure if that use case is useful for stack though.

[harendra-kumar]

The discussion in #1365 is related to this. Some stack config commands are proposed there as well.

[sjakobi]

augeas is a nice tool to manipulate config files in a generic way.

One advantage of augeas would be that according to its FAQ:

Augeas works very hard to preserve comments and formatting details such as the number of spaces used to separate fields etc.

Augeas even has Haskell bindings although these have not been updated since 2012.

It seems though that augeas is Unix-only, so any use of augeas, whether via the bindings on by providing lenses for use with augtool, would exclude Windows users.

[mgsloan]

It does seem that an augeas port to windows may be within reach. This branch is a bit behind, but sounds promising: https://tickets.puppetlabs.com/browse/PUP-4971 https://github.com/MikaelSmith/augeas/tree/windows

I haven't worked with augeas, but I am certainly in favor of such re-use when it's possible and it works well. On the other hand, refactoring yaml is an interesting problem to me, that I wouldn't mind having a swing at it (readers, feel free to leave a comment here and have a swing at it yourself! Not sure when this implementation will actually happen).

[snoyberg]

I think we've implemented as much of this as desired for now. New requests can go into new issues.