Use stack init logic for global stack build

[mgsloan]

"haskell830" on #haskell was trying to install structured-haskell-mode via stack install structured-haskell-mode, and it didn't work because it's not updated to work with lts-4.

Perhaps when the build plan fails with the global project, we could run stack init's logic to determine a better snapshot, and then suggest instead running stack build --resolver lts-3.22 structured-haskell-mode.

One thing to consider is whether we'd add --solver as a build flag. Similarly to how the --resolver build flag overrides the resolver field, this would override extra-deps.

[harendra-kumar]

That's a good idea. And if we use --solver then should we also dump the actual config used by build in a file?

Another possibility is to use stack solver --update-config for this use case. Though stack solver does not change the resolver as of now; we can add a flag to it to auto-select and override the existing resolver.

[harendra-kumar]

How about --resolver auto? It can be used for stack solver as well as for stack build to choose the best resolver automatically. And it is the default for stack init.

[mgsloan]

And if we use --solver then should we also dump the actual config used by build in a file?

Could write it to a temp location, but I'm not sure where it'd go if we did write it somewhere.

Another possibility is to use stack solver --update-config for this use case. Though stack solver does not change the resolver as of now; we can add a flag to it to auto-select and override the existing resolver.

Right! I'm not sure if we should encourage automatic updates to the global project, though.

How about --resolver auto? It can be used for stack solver as well as for stack build to choose the best resolver automatically. And it is the default for stack init.

Hmm, that could work decently. I'd really rather not support resolver: auto in stack.yaml files though. If it re-does the auto step for each build, it could slow things down a lot.

[mgsloan]

After considering this further, I think it makes sense to only search for a better snapshot, and report the best match. It should also suggest making a new stack.yaml or modifying the global project, if you want to do something fancier. This might detail how to stack unpack the target package and init a stack.yaml.

Also, this should only be done when the build targets include non-local packages (like stack install structured-haskell-mode, where it's not a local package of the global project).

[harendra-kumar]

I'm not sure if we should encourage automatic updates to the global project, though.

I did not mean automatic here. I meant the user invoking stack solver --update-config if the build fails. That will fix the config.

I'd really rather not support resolver: auto in stack.yaml files though.

True. auto does not make sense at all for the config file, it can only be thought of as a CLI option.

I could not understand the last bit. I guess the local/non-local terminology is not clear to me.

[harendra-kumar]

I got bitten by this myself today when trying to install present. I want to install it via an automated non-interactive script. I think we need a do-whatever-it-takes mode for installing external packages. As we discussed above, there are two ways and we may need both:

• stack install <external package> --solver . This will use the default/global project resolver but will add external dependencies when needed.
• stack install <external package> --resolver auto. This will fallback to other resolvers if the default/global project does not work. Or we could call it --resolver any which means that we don't care about the resolver, choose whatever works.

We can also combine the two options to try both - add external deps as well as scan to find the best resolver. This will be the most general do-whatever-it-takes config.

@mgsloan thoughts? Should we bundle this in just one option (with less flexibility) or have both of the above?

[harendra-kumar]

Can we have these for project packages as well or restrict to just external packages? I think for uniformity we should have for both. It cannot cause any harm as these are explicit options and not defaults. One would want to treat a locally available package just like an external package when she is only concerned with installing the package and not developing it.

[harendra-kumar]

I saw scripts adding extra deps to global project for solving this problem like this one here. This also leaves the extra deps after the script finishes and might interfere with other installs. We need to get rid of such ugliness by design.

[mgsloan]

Closing in favor of #2656