Allow --pvp-bounds to use multiple stack.yaml configurations

[mgsloan]

This is split off from #1568, which focused on having multiple configurations in a single stack.yaml file.

As @sjakobi suggests, it's quite reasonable to still have a --pvp-bounds flag which uses multiple configs:

How about specifying the extra stack.yamls to consider with an optional flag to --pvp-bounds, e.g. --also-considering?
Example command: stack sdist --pvp-bounds both --also-considering stack-7.8.yaml stack-8.0.yaml.

Folks would probably want to automate this via a Makefile or script.

[borsboom]

I'm very much in favour of this. It'd be super useful when uploading stack itself to Hackage.

[DanBurton]

+1 looks like a very sensible user interface to add needed flexibility to --pvp-bounds.

[sjakobi]

I'm wondering if we could get away without having a separate stack.yaml for each dependency configuration that should be considered.

With the current feature idea, if I had a simple library, I'd create a directory other-stack-yamls that contains a bunch of stack-lts-X.yaml files containing only the resolver line with one X for each lts generation that I want to support and then run stack sdist --pvp-bounds both --also-considering other-stack-yamls/stack*.yaml when making a release.

So what I'm currently thinking, is that it should be possible to pass both stack.yaml file names and snapshot names to --also-considering, so you could say e.g.

stack sdist --pvp-bounds both --also-considering stack-7.8.yaml lts-4 nightly-2016-06-19

Thoughts on that, anyone?

Ideally it would also be easy to run tests with the same list of dependency configurations.

[mgsloan]

@sjakobi Seems like a good approach to me! Perhaps we should allow stack.yaml filepaths in generaal for --resolver? I do not see a downside. It is shorter and easier to type than --stack-yaml.

[DanBurton]

Well, there can be a lot more config than just the resolver in the stack.yaml file; it doesn't make sense to me to allow a file for the --resolver flag.

[sjakobi]

Perhaps we should allow stack.yaml filepaths in generaal for --resolver? I do not see a downside. It is shorter and easier to type than --stack-yaml.

Assume that there's a file stack.yaml:

packages:
- pkg1
- pkg2
resolver: lts-6.4

and a file stack-8.0-testing.yaml:

packages:
- pkg1
resolver: nightly-2016-06-24

Which packages would stack --resolver stack-8.0-testing.yaml build build?

I think I agree with @DanBurton that you sometimes want to use the standard config (stack.yaml) with a different resolver and sometimes want to use an entirely different config, in which case it's clearest to specify it with the --stack-yaml option.

As I've written in #2238 I would though like to be able to specify a resolver manually and ignore any extra-deps that are specified in the stack.yaml. I think I'm even in favor of changing the semantics of --resolver for this.

BTW, I've started implementing this issue. In this context --also-considering lts-6.4 will mean "use the versions from lts-6.4 for all non-local dependencies, ignoring any extra-deps listed in the stack.yaml".

[sjakobi]

Right now I'm thinking that this could be the basis for a "test-driven version bounds" style of package management.

What's missing is a command stack gen-lower-bounds-config that generates a stack config stack-lower-bounds.yaml from the given lower bounds in a .cabal file. The resolver could simply be the oldest snapshot that uses a compatible GHC version. The lower bounds from the .cabal file should go into the extra-deps. The package author would probably have to edit the stack-lower-bounds.yaml a bit to make it buildable and could then delete the lower bounds in their .cabal file.

If the stack-lower-bounds.yaml is used for CI it will always inform the package author when they lose compatibility with a dependency version so they can either regain compatibility or adjust the stack-lower-bounds.yaml.

If the author then creates their sdist with stack sdist --pvp-bounds both --also-considering stack-lower-bounds.yaml they can be reasonably confident that the package will indeed build with all admissible dependency versions.

Thoughts?

You may BTW chime in on the various open design issues in my PR.