New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add commands for automating stack.yaml management #115

Open
snoyberg opened this Issue May 29, 2015 · 16 comments

Comments

Projects
None yet
@snoyberg
Contributor

snoyberg commented May 29, 2015

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

@snoyberg snoyberg added this to the Later improvements milestone May 29, 2015

@chrisdone

This comment has been minimized.

Member

chrisdone commented May 29, 2015

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

This comment has been minimized.

Contributor

gregwebs commented May 29, 2015

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

This comment has been minimized.

Member

chrisdone commented May 29, 2015

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

This comment has been minimized.

Member

chrisdone commented May 29, 2015

(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

This comment has been minimized.

Contributor

gregwebs commented May 29, 2015

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

This comment has been minimized.

Contributor

chreekat commented Jun 9, 2015

+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

This comment has been minimized.

Contributor

rvion commented Jun 9, 2015

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

@snoyberg snoyberg modified the milestones: 0.2.0.0, Later improvements Jun 16, 2015

@snoyberg snoyberg modified the milestones: 0.2.0.0, 0.3.0.0 Jul 2, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jul 2, 2015

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

This comment has been minimized.

Contributor

alanz commented Jul 2, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jul 2, 2015

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.

@snoyberg snoyberg modified the milestones: Later improvements, 0.3.0.0 Sep 6, 2015

@ekmett

This comment has been minimized.

ekmett commented Sep 21, 2015

👍 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

This comment has been minimized.

Contributor

drwebb commented Nov 11, 2015

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

This comment has been minimized.

Collaborator

harendra-kumar commented Jan 2, 2016

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

This comment has been minimized.

Collaborator

harendra-kumar commented Jan 2, 2016

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

@sjakobi

This comment has been minimized.

Contributor

sjakobi commented Jul 12, 2016

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

This comment has been minimized.

Collaborator

mgsloan commented Jul 19, 2016

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment