Skip to content

Figure out project initialization #253

@snoyberg

Description

@snoyberg

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 new create a complete project from a template, which addresses the "brand new project" case
  • stack build automatically creates a stack.yaml already, but additionally throw in a stack init command to be more explicit about it, and let that command have more flags to control behavior. @gregwebs brought up the idea of naming this stack config instead, and letting it double as a means of modifying an existing stack.yaml
  • stack setup will 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.)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions