-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Does the experimental.new-installer check for package hash mismatch? #7347
Description
- Poetry version: Poetry (version 1.3.2)
- Python version: 3.9.16
- OS version and name: Debian GNU/Linux 11
- pyproject.toml: https://gist.github.com/haydenseitz/3a72cd1cbf2b44af43a8de2779a7fe3f#file-pyproject-toml
- I am on the latest stable Poetry version, installed using a recommended method.
- I have searched the issues of this repo and believe that this is not a duplicate.
- I have consulted the FAQ and blog for any relevant entries or release notes.
- If an exception occurs when executing a command, I executed it again in debug mode (
-vvvoption) and have included the output below.
Issue
I stumbled upon a difference in behavior between the default installer (experimental.new-installer true) and the legacy(?) installer (experimental.new-installer false). I recently found that a package version hash changed, and it was causing my local poetry install to fail. However, our CI builds were still working, as well as other colleagues' local builds.
To reproduce, here is a poetry.lock file that has the old hash for the python-crontab package. Disable the new installer with poetry config experimental.new-installer false, use the provided pyproject.toml and poetry.lock, and run poetry install. The install should fail with a hash mismatch for python-crontab. However, when trying the same steps with poetry config experimental.new-installer true, I do not get a mismatch error, and the package with a different hash seems to be installed. Is there an issue here or is something else going on with the new installer?