Flag to refresh lockfile for specific dependency

[ChickenProp]

Suppose I'm using packageB, which depends on packageA, and in my extra-deps I have

- packageA-1.0.0
- packageB-1.0.0

Additionally, my stack.yaml.lock locks packageB at revision 1, which has a version bound packageA < 1.1.0.

Now I update to packageA-1.1.0. I check hackage, and there's no new version of packageB, but there is a revision 2, that loosens the bounds. How do I update to that revision?

One way is to replace the packageB dep with packageB-1.0.0@rev:2. Maybe this is what we're expected to do? But in practice I feel like I've basically never seen an @rev in a stack.yaml file. If I did see one, I'd assume it was because there was a more-recent revision that was explicitly being excluded for some reason. So I'm reluctant to do that.

Another way is to delete the stack.yaml.lock file and rebuild. A new one gets generated that'll have the most recent revision of packageB. But that also potentially updates a load of other revisions, which I might not want.

A third way is to replace the packageB dep, rebuild, and then put it back to package-1.0.0 as it is currently and rebuild again. (I don't think the intermediate rebuild needs to succeed, but I guess it needs to construct a build plan.) This updates just the packageB revision in the lockfile, and in terms of results it's the option I like the most.

But it's also not at all obvious. So it might be good to have a flag like stack build --refresh-lockfile=packageB, that would use the latest revision regardless of what's in the lockfile, and then lock that revision for future runs.

Combined with #5969, it might be helpful to offer a suggestion to use this flag, when a build fails because packageA's version isn't supported by the current revision of packageB, but it is by a more recent revision.

[mpilgrem]

@ChickenProp, thanks for reporting. I am working through open issues, including older ones.

Personally, I think that you hit the nail on the head when you asked: "Are we expected to replace the packageB dependency in the project-level configuration file with packageB-1.0.0@rev:2?", for the following reasons:

• the dangers of not fully specifying the contents of the project-level configuration file, as it relates to immutable extra-deps, is set out in Stack's online documentation, at https://docs.haskellstack.org/en/stable/pantry/#hackage-packages;

• Stack's lock files exist to save users from the chore of having to fully specify the contents of the project-level configuration file, day to day: https://docs.haskellstack.org/en/stable/lock_files/. That said, it is not unknown for immutable extra-deps to be specified precisely in the project-level configuration file; that is what the Stack project does, for example, in its own stack.yaml; and

• the downside is that if the lock file no longer fully specifies what the user actually wants (in your case, a different Cabal revision of the package version in the package index), that does have to be specified in the project-level configuration (which will trigger the recreation of the lock file on disk - as will the deletion of the lock file).

That is, I see the project-level configuration file as the 'main focus' for reproducible builds and the lock file as a 'convenience'. It seems to me unprincipled to shift the focus of build specification from the configuration file to the lock file.