-
Notifications
You must be signed in to change notification settings - Fork 844
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
Stack init and solver finish up and doc update #1674
Conversation
When doing stack init, some of the packages may not be compatible with the resolver compiler while others just build ok. In that case we provide the user an option to ignore those packages and use the rest. If --force is specified stack will create a config with those packages which are compatible. Fixes commercialhaskell#1621
Warnings about: - ignored packages - extra dependencies
Packages which are not compatible with the resolver are added to the config but commented out. See commercialhaskell#1621
When there are some issues with the config file add warning messages for the user to be displayed everytime the config file is read. The messages can be suppressed by a user action i.e. remove it from the config if the user accepts the config. See commercialhaskell#1621
When there is an unresolved conflict among the dependencies of multiple source packages then remove one of the conflicting packages and then retry. The package chosen to be removed is the one which is on top of the dependency pyramid i.e. noone else depends on it. The functionality is not yet complete. It will be complete once cabal output is parsed and the list of conflicting packages is fed to the upper level logic. See commercialhaskell#1616
When there is an unresolvable conflict among the dependencies of multiple user packages ignore one of them and try again to resolve the rest. This commit adds code for parsing cabal output to find out user packages involved in the conflict. This output is then used to decide one of those packages to be ignored from consideration in the next try. Fixes commercialhaskell#1616
When using stack init if duplicated package names are found automatically ignore the duplicates with a warning.
Remove the overloading of --force option and use it exclusively for overwriting an existing config. Use a separate --omit-packages option for excluding conflicting or incompatible packages from generated config. See commercialhaskell#1621
When all resolver compilers are incompatible with some user packages then choose the one which can build maximum number of packages rather then the one with least number of compiler incompatibility errors.
Remove the affinity to existing in-use snapshots. Try latest major lts, then latest nightly and then all other major lts versions in the most recent first order. Fixes commercialhaskell#1628
stack init now uses the global --resolver option instead of its own implementation of the same. This changes the CLI behavior: you will have to use `stack --resolver lts-4.1 init` instead of `stack init --resolver lts-4.1` Fixes commercialhaskell#1588
Detect duplicates based on the cabal package name instead of the file name.
If the cabal file does not have a name assigned to a package then display an error and exit. Otherwise empty names will cause strange errors later on. Also added code to dislay cabal error output when we cannot parse it.
Packages in upper level directories are likely to be more important and therefore try to pick those when there is a conflict in packages.
Lot of things changed with the recent changes in stack init.
Since stack does not allow package name to mismatch with the .cabal file name stack init should also not allow that. This commit disallows the mismatch.
Now that there is no local --resolver option for stack init we can allow the global option to be used in subcommand context. This was disabled by the fix for commercialhaskell#1531. I have reverted the init specific fix for that but kept the overall mechanism for any future use.
Looks awesome, thanks! I'll come back with more detailed feedback sometime in the next couple days. |
Sorry for letting this languish so long! I've taken a look at the commits, and they look great. Since I only have a couple comments / tweaks, I'm going to go ahead and merge this and fix them myself. |
Stack init and solver finish up and doc update
Thanks! Did you look at the doc changes? |
Yup, I did! Also LGTM |
Provide, working out of the box experience, for
stack init
andstack solver
commands. Important fixes in this PR include:The documentation in the user guide provides more information and workflow examples.
With these fixes stack init experience must now become much better. We should be able to generate a working stack.yaml for most packages without any issues. If a package has working cabal files and cabal can build it but we are not able to generate a stack.yaml out of the box then it should be considered a bug!