Replace Stack.Snapshot with code using SourceMaps

[qrilka]

After #3922 gets merged there will be 2 different ways to deal with snapshots:

1. The old one in Stack.Snapshot
2. New source maps from Stack.Types.SourceMap

It makes sense to remove code duplication coming from this

[qrilka]

@snoyberg after looking more into it I'm inclined to remove Stack.Solver (i.e. resolve #4410 ) as a part of fixing this. I suppose there are no objections from your side?
(The main motivation is --solver option of stack init which is also to be removed)

[snoyberg]

To be clear, this would mean we would be completely removing the dependency solver integration, including the solver command and stack init --solver, right?

[qrilka]

Yes, that's my current suggestion, also there's an additional point: what to do with stack init --resolver=ghc-8.2.2? In the current code we switch to --solver in this case, if it will be removed the only choice I see is trying out boot packages-based resolver (i.e. rely on the information from global-hints.yaml)

[snoyberg]

We should probably at least ask on the mailing list before doing that, though my inclination is in that direction.

I'd say that the --resolver case should be fairly simple: we just create the stack.yaml file even if it's invalid.

[qrilka]

@snoyberg I don't quite get the last point - why do you think it could be invalid? My suggestion was to treat it as a Stackage snapshot with only difference that deps part of a source map will be empty (and only globals will be available), otherwise snapshot will be checked and no stack.yaml will be created in case of existing errors.
After having a look into #3397 now it seems to me that using global-hints.yaml for a GHC resolver could be not the best option - do you still agree with what you've written in 2017 and we need to use proper GHC to get information about boot libraries?
And regarding mailing list - do we have any particular policy about that? Should I just do more or less the same announcement that you've done for STACK_LOCK and continue with the change?

[snoyberg]

why do you think it could be invalid?

Because the local packages don't support the GHC version specified, or require packages beyond what ships with GHC.

My suggestion was to treat it as a Stackage snapshot with only difference that deps part of a source map will be empty (and only globals will be available), otherwise snapshot will be checked and no stack.yaml will be created in case of existing errors.

You've got the right idea, I was misremembering the behavior of stack init. I thought it would create the stack.yaml anyway, but I see that in fact it doesn't:

Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- ./

Selected resolver: https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/13/13.yaml
Resolver 'https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/13/13.yaml' does not have all the packages to match your requirements.
    acme-missiles not found
        - foo requires -any

This may be resolved by:
    - Using '--solver' to ask cabal-install to generate extra-deps, atop the chosen snapshot.
    - Using '--omit-packages' to exclude mismatching package(s).
    - Using '--resolver' to specify a matching snapshot/resolver

do you still agree with what you've written in 2017 and we need to use proper GHC to get information about boot libraries?

Given my bad memory about the behavior of stack init: yes, that seems prudent.

And regarding mailing list - do we have any particular policy about that? Should I just do more or less the same announcement that you've done for STACK_LOCK and continue with the change?

Yes. I'd give it three days before proceeding.