Have something like "stack install --use-stack-yaml-from hackage-pkg"?

[mgsloan]

For situations like #2039 , where the user does stack install a-non-stackage-hackage-package, the issue is that we don't know what package versions to use for things outside our resolver. As discussed in that issue, one way to resolve this is to support a --solver flag and create a temporary sandbox for this particular build.

Another approach might be to actually just use the stack.yaml included with the package, if it exists. This
might be a reason to include it by default in sdists: #2105

This way we can directly tell the user how the package author intended for it to be installed.

Open questions: What about multiple stack files?

[sjakobi]

Slightly related: #2371 was opened under the assumption that stack should use the flag settings in the stack.yaml included in an sdist tarball.

[joeyh]

Due to stack install pkg ignoring the stack.yaml shipped with pkg, I have to tell my users not to use stack install pkg, and instead get the source themselves and stack install it. This is despite the pkg in question being in stackage.

[mgsloan]

@joeyh Good to know, bumping priority to P2.

I'm thinking that the resolution to this would look something like:

1. Warn the user when they are stack install-ing an executable that came with a stack.yaml. Tell them about the --use-sdist-stack-yaml flag.

2. Add a --use-sdist-stack-yaml flag. You're only allowed to specify hackage targets, and they all must have their own stack.yaml.

Would that be sufficient?

[joeyh]

Michael Sloan wrote:

@joeyh Good to know, bumping priority to P2.

I'm thinking that the resolution to this would look something like:

1. Warn the user when they are stack install-ing an executable that came with a
   stack.yaml. Tell them about the --use-sdist-stack-yaml flag.

2. Add a --use-sdist-stack-yaml flag. You're only allowed to specify hackage
   targets, and they all must have their own stack.yaml.

Seems reasonable.

see shy jo