-
Notifications
You must be signed in to change notification settings - Fork 847
Closed
Description
We have a number of different issues all touching on the topic of project initialization (#116 #137 #228 #229). I'd like to use this issue to take a step back and discuss goals at a higher level to try and come up with solution that addresses everything.
It seems like we have the following different use cases that are overlapping:
- Start a brand new project without any source code preexisting
- Take a preexisting Cabal package (with a single .cabal file) and create a stack.yaml file
- Take a preexisting mega-repo (multiple .cabal files) and create a stack.yaml file
- Figure out the best resolver settings to use for 1 or more existing .cabal files
- Deal well with the case where no LTS or Nightly is found that can compile the user's code
- Upgrading a stack.yaml to a newer snapshot
- Installing GHC
Possibly related ideas on the table already are:
stack newcreate a complete project from a template, which addresses the "brand new project" casestack buildautomatically creates a stack.yaml already, but additionally throw in astack initcommand to be more explicit about it, and let that command have more flags to control behavior. @gregwebs brought up the idea of naming thisstack configinstead, and letting it double as a means of modifying an existing stack.yamlstack setupwill download and install GHC if missing. There was some discussion about that command name being confusing- For cases where no LTS or Nightly works, we currently fall back to an LTS. Instead, we could fall back to using a dependency solver to create a set of extra-deps (or use custom snapshots when available Custom snapshots #111)
I think that summarizes the goals and proposals until now. Before diving into solving all of these things coherently, does anyone want to add more requirements to the mix?
(Assigning to myself to drive the discussion forward, but others should feel free to jump in, make decisions, and implement things.)