Closed akshaymankar closed 7 months ago
Just ran into this as well while upgrading to the new LTS snapshot, it's quite annoying. (Stack version 2.9.3.)
--allow-newer
is a non-project specific configuration flag.
Updating the example above for more recent developments and using Stack 2.11.1:
resolver: lts-20.19
packages: []
extra-deps:
# lts-20.19 does not include megaparsec
- megaparsec-9.0.0
allow-newer: true
stack install config-ini-0.2.3.0
builds, and yields (extracts):
Warning: Ignoring config-ini's bounds on containers (>=0.5 && <0.6) and using containers-0.6.5.1.
Reason: allow-newer enabled.
Warning: Ignoring megaparsec's bounds on bytestring (>=0.2 && <0.11) and using bytestring-0.11.4.0.
Reason: allow-newer enabled.
Warning: Ignoring config-ini's bounds on megaparsec (>=7 && <8) and using megaparsec-9.0.0.
Reason: allow-newer enabled.
Switching then to allow-newer: false
:
stack install config-ini-0.2.3.0 --dry-run
yields:
No packages would be unregistered.
Nothing to build.
No executables to be installed.
There are no warnings because there is nothing in constructing the actual build plan to warn about.
If the relevant snapshots
that have been created in the Stack root are deleted (so something has to be built, once again), then stack install config-ini-0.2.3.0 --dry-run
yields:
Error: [S-4804]
Stack failed to construct a build plan.
While constructing the build plan, Stack encountered the following errors:
In the dependencies for config-ini-0.2.3.0:
containers-0.6.5.1 from Stack configuration does not match >=0.5 && <0.6 (latest matching version is 0.5.11.0)
needed since config-ini is a build target.
In the dependencies for megaparsec-9.0.0:
bytestring-0.11.4.0 from Stack configuration does not match >=0.2 && <0.11 (latest matching version is 0.10.12.1)
needed due to config-ini-0.2.3.0 -> megaparsec-9.0.0
Some different approaches to resolving this:
* Set allow-newer: true in C:\sr\config.yaml to ignore all version constraints and build anyway.
* Recommended action: try adding the following to your extra-deps in D:\Users\mike\Code\Haskell\foo\stack.yaml:
- bytestring-0.10.12.1@sha256:82dba4c2de4fdd8b419ed28aec2c14cfe4a3f43d1d6e2263ab26962e7398048e,6254
- containers-0.5.11.0@sha256:1af9da3baaddc4f4aaea016b07d4c38ddbf702ce3f0df31120531950837996b8,17308
--allow-newer
should, I think, be understood as a strategy to overcome problems (if any) in constructing the actual build plan. I don't think --allow-newer: false
in a project's stack.yaml
file should be understood as a guarantee that a build plan can be constructed.
Notes to self:
allow-newer
is not a component of the value of a Stack.Types.SourceMap.DepPackage
or Stack.Types.SourceMap.CommonPackage
.Stack.Build.Source.depPackageHashableContent
.
General summary/comments (optional)
If a package is compiled with
allow-newer: true
in thestack.yaml
and thenallow-newer
is removed (or madefalse
), stack does not complain about it anymore. Evenstack clean
does not help. This can make someone believe, for instance after a snapshot update, that they no longer needallow-newer
when they do need it.Steps to reproduce
For example (I picked these packages from issues in the stackage repo):
Create stack.yaml in an empty directory with contents:
stack install config-ini
.stack.yaml
and remove theallow-newer
linestack install config-ini
.Expected
Stack should tell me that dependency resolution doesn't work out.
Actual
Command succeeds, nothing is printed.
Stack version
Method of installation