commercialhaskell / stack

The Haskell Tool Stack
http://haskellstack.org
BSD 3-Clause "New" or "Revised" License
3.99k stars 845 forks source link

Removing allow-newer doesn't cause any errors when it should #5406

Closed akshaymankar closed 7 months ago

akshaymankar commented 4 years ago

General summary/comments (optional)

If a package is compiled with allow-newer: true in the stack.yaml and then allow-newer is removed (or made false), stack does not complain about it anymore. Even stack clean does not help. This can make someone believe, for instance after a snapshot update, that they no longer need allow-newer when they do need it.

Steps to reproduce

For example (I picked these packages from issues in the stackage repo):

  1. Create stack.yaml in an empty directory with contents:

    resolver: lts-16.16
    packages: []
    extra-deps:
    - megaparsec-9.0.0
    
    allow-newer: true
  2. Run command stack install config-ini.
  3. Edit stack.yaml and remove the allow-newer line
  4. Run command stack install config-ini.

Expected

Stack should tell me that dependency resolution doesn't work out.

Actual

Command succeeds, nothing is printed.

Stack version

$ stack --version
2.3.3 x86_64 hpack-0.34.2

Method of installation

isomorpheme commented 1 year ago

Just ran into this as well while upgrading to the new LTS snapshot, it's quite annoying. (Stack version 2.9.3.)

mpilgrem commented 1 year ago

--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.

mpilgrem commented 1 year ago

Notes to self: