Skip to content
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

Allow restraining snapshot selection #229

Closed
cocreature opened this issue Jun 9, 2015 · 12 comments
Closed

Allow restraining snapshot selection #229

cocreature opened this issue Jun 9, 2015 · 12 comments
Assignees
Milestone

Comments

@cocreature
Copy link
Contributor

I'd like to have an option to select the snapshot when running stack build instead of relying on stack to figure it out for me and if it is wrong cancelling, editing the yaml file and rerunning it.

@snoyberg
Copy link
Contributor

snoyberg commented Jun 9, 2015

I think the solution here will end up being very close to what we do for #228, so the two issues should be considered together (possibly even merged into a single issue actually).

@snoyberg snoyberg added this to the First stable release (0.1.0.0?) milestone Jun 9, 2015
@cocreature
Copy link
Contributor Author

Feel free to merge/close this issue if it's covered my #228.

@gregwebs
Copy link
Contributor

gregwebs commented Jun 9, 2015

This issue is potentially asking for a stack init command that creates a stack.yaml that can be edited before any dependencies are downloaded. Right now #228 seems focused on the ghc part.

@snoyberg
Copy link
Contributor

snoyberg commented Jun 9, 2015

Adding a stack init is a really easy first step to take here, and we can iterate from there.

@snoyberg
Copy link
Contributor

snoyberg commented Jun 9, 2015

Bikeshedding: do we have a problem with the command init due to its preexisting meaning with cabal (initialize a package)? There's also some naming overlap with the proposed stack new from #137.

@chreekat
Copy link
Member

chreekat commented Jun 9, 2015

There could be a single command that does the right thing. If stack build would build packages, stack init would simply create the yaml. If stack build would fail with PackageNoCabalFileFound "/home/b/tmp/foo/", stack init would ask to set up a new project.

stack build already manages the second scenario, sort of, since it still creates a stack.yaml even if there is no cabal file found. Could be improved.

There's also a question of what to do when creating a multi-package project. Right now stack build ignores that scenario, but perhaps it and stack init could just snoop one subdirectory level down on the hunt for cabal files.

snoyberg added a commit that referenced this issue Jun 9, 2015
@snoyberg
Copy link
Contributor

snoyberg commented Jun 9, 2015

I've pushed a simple commit to the 229-stack-init branch that implements the basics of an init command.

One thing I'm concerned about is trying to make init too smart. When it comes to large, multi-package projects, is very unlikely that stack will ever guess correctly what you want to do. In fact, as we're seeing in this issue and #228, it's very difficult for it to guess right now what the user would want to do in even somewhat complicated cases.

I think instead of becoming too magical, it would make more sense to generate a basic stack.yaml and explain to the user (via docs on the website and comments in the generated file) how to proceed.

@gregwebs
Copy link
Contributor

gregwebs commented Jun 9, 2015

Sure, it might make sense to give it a different name. I am wondering if init should be used for #137 and this should be called new. Or this could be stack config. stack config would end up being a sub command, but with no extra options when there is no stack.yaml it would generate a stack.yaml.

@snoyberg
Copy link
Contributor

snoyberg commented Jun 9, 2015

Hmm I like that.

On Tue, Jun 9, 2015, 7:29 PM Greg Weber notifications@github.com wrote:

Sure, it might make sense to give it a different name. I am wondering if
init should be used for #137
#137 and this should
be called new. Or this could be stack config. stack config would end up
being a sub command, but with no extra options when there is no stack.yaml
it would generate a stack.yaml.


Reply to this email directly or view it on GitHub
#229 (comment)
.

@gregwebs
Copy link
Contributor

gregwebs commented Jun 9, 2015

Another thing I have been thinking about is that stack setup seems to be focused on ghc. I would actually expect this to be what stack setup should do (in addition to stating: I can't find GHC, you can install it with stack setup --ghc).

There are different points in the design space, good thing we are still in beta :)

@snoyberg
Copy link
Contributor

I've opened #253 to try and discuss this and other related topics together

@snoyberg snoyberg self-assigned this Jun 15, 2015
@snoyberg
Copy link
Contributor

Solved by the --resolver flag, see #253 (comment). Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants