Stack init and solver finish up and doc update #1674
Provide, working out of the box experience, for
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!
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 #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 #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 #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 #1616
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 #1531. I have reverted the init specific fix for that but kept the overall mechanism for any future use.
I was having two minds when I did this but ultimately just chose this way. If you think about this data type as a test result measure then then this makes more sense. We perhaps would always want to compare this data type in terms of how good the match was rather than comparing it in the literal sense.
I don't mind using a separate function approach too if that looks clearer.
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.