New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hashes are used although pip-compile was instructed to compile from scratch using --rebuild #2056
Comments
I already tried running |
Do you have a config file lying around? Do you use |
No config-file used ( except the |
I suspect that pip is comparing the hash of the currently installed package But why should this be the case - I wanted |
Was it previously recorded in the constraints txt file? Normally, pip demands hashes everywhere when it sees at least one |
Does it still output that |
Also, how is |
Also, grep for |
Yes, but only as the resolved version, e.g.
It was configured as
A sub-dependency was also depending on a compatible/same version, referring to it in its own dependencies as
No.
No, there is no corresponding
No results when executing We have refactored the way we publish our packages to the private pypi repo, not re-using the same version on publishing an updated ( rc versioned ) package, as this seems to be in general a bad approach. I will try to reproduce the issue again and try out the idea of |
we just encountered what looks like this issue: pip-compile --quiet --upgrade --output-file requirements/dev-linux-3.12.lock requirements/dev.in
Traceback (most recent call last):
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/bin/pip-compile", line 8, in <module>
sys.exit(cli())
^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/click/core.py", line 1157, in __call__
return self.main(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/click/decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/piptools/scripts/compile.py", line 469, in cli
results = resolver.resolve(max_rounds=max_rounds)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/piptools/resolver.py", line 604, in resolve
is_resolved = self._do_resolve(
^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/piptools/resolver.py", line 636, in _do_resolve
resolver.resolve(
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/resolution/resolvelib/resolver.py", line 179, in resolve
self.factory.preparer.prepare_linked_requirements_more(reqs)
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/operations/prepare.py", line 552, in prepare_linked_requirements_more
self._complete_partial_requirements(
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/operations/prepare.py", line 487, in _complete_partial_requirements
self._prepare_linked_requirement(req, parallel_builds)
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/operations/prepare.py", line 612, in _prepare_linked_requirement
hashes.check_against_path(file_path)
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/utils/hashes.py", line 106, in check_against_path
return self.check_against_file(file)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/utils/hashes.py", line 102, in check_against_file
return self.check_against_chunks(read_chunks(file))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/utils/hashes.py", line 91, in check_against_chunks
self._raise(gots)
File "/home/runner/work/pydux/pydux/pydux/.nox/devenv-3-12/lib/python3.12/site-packages/pip/_internal/utils/hashes.py", line 94, in _raise
raise HashMismatch(self._allowed, gots)
pip._internal.exceptions.HashMismatch: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
unknown package:
Expected sha256 ca1cb80a17d6999c827815ba10cfcb7fd8deaf0db176d06549ca266298390da8
Got 405cf084fd8fc3cc7038a187ad233bce9c9f960ebf93281965c95e11e8925c04 here's the details of the environment this happened in: (click to expand) cache state, dependency versions, config, and inputsCPython 3.12.2 in an ephemeral CI runner: GHA's ubuntu-latest. the job started with no pip/pip-tools caches. the first step was checkout, the second was - name: Set up Nox
uses: wntrblm/nox@6646b24d62e69442a55502e460e33c252d54beb4
with:
python-versions: '3.12' notably this step modifies pip's cache via the next step created a virtualenv (everything after ocurred in that virtualenv) and did pip install -c requirements/dev-linux-3.12.lock pip-tools
pip-sync requirements/dev-linux-3.12.lock
pip install -c requirements/dev-linux-3.12.lock -e .
pip install -c requirements/dev-linux-3.12.lock pytest-github-actions-annotate-failures
pip-compile --quiet --upgrade --output-file requirements/dev-linux-3.12.lock requirements/dev.in # this is the one that raised the HashMismatch the package at [build-system]
requires = [
"hatchling",
"hatch-vcs",
]
build-backend = "hatchling.build" pip-tools config files are just: [tool.pip-tools]
strip-extras = true
allow-unsafe = true
some investigation revealed that <a href="https://files.pythonhosted.org/packages/9b/6e/141227fbab01d4f413702627fb286f3e118264d5e0b3300d0cf871eba991/qutip-5.0.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl#sha256=ca1cb80a17d6999c827815ba10cfcb7fd8deaf0db176d06549ca266298390da8" data-dist-info-metadata="sha256=0cca2dcd4bf5f592a1f66c827f32bfe3a679662f65105b07b42ac1ffda916b7a" data-core-metadata="sha256=0cca2dcd4bf5f592a1f66c827f32bfe3a679662f65105b07b42ac1ffda916b7a">qutip-5.0.0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl</a><br />
beyond that, i don't know how it received/wrote/hashed a corrupted/different file. second instancei attempted many times to reproduce this with some investigation revealed that <a href="https://files.pythonhosted.org/packages/4d/e2/e8f2f0ca8e65beef392ed8847ad6b30375d36cac55a7769d8af472831fef/qutip-5.0.0-cp312-cp312-macosx_10_9_x86_64.whl#sha256=3f2f7b774b07c1c87c4872ffb3a49bf45fb6aefba011f35d18f36f1c51bec05e" data-dist-info-metadata="sha256=0cca2dcd4bf5f592a1f66c827f32bfe3a679662f65105b07b42ac1ffda916b7a" data-core-metadata="sha256=0cca2dcd4bf5f592a1f66c827f32bfe3a679662f65105b07b42ac1ffda916b7a">qutip-5.0.0-cp312-cp312-macosx_10_9_x86_64.whl</a><br />
anyway, here's
i noticed that the logged HTTP response length 10187154 is the correct length of i'm not sure why both instances i have seen this bug in have both involved qutip 5.0.0 wheels. at time of writing qutip 5.0.0 was released to PyPI 3 days before both of the two buggy runs above. these wheels were uploaded 3 days ago too; qutip didn't do delayed uploading of wheels there. anyway, let me know if you have any ideas based on this info. perhaps we just got unlucky with some errors that passed TCP's weak checksums? perhaps some tiny fraction of PyPI's nodes have some rotted files for qutip 5.0.0 cached? i've got no clue. |
Environment Versions
$ python -V
: Python 3.10.6$ pip --version
: pip 24.0$ pip-compile --version
: pip-compile, version 7.4.0Scenario
Using a private PyPi repository, the same version of a package was published multiple times using different hashes between consecutive invocations of
pip-compile
.The scenario is as follows:
pip-compile --verbose --no-emit-index-url --rebuild --resolver=backtracking /Users/user/myproject/requirements.in
pip-compile --verbose --no-emit-index-url --rebuild --resolver=backtracking /Users/user/myproject/requirements.in
againThe second run of
pip-compile
complains about a possible tampered package - but I have not put any hashes in therequirements.in
or the previously compiledrequirements.txt
.The output of the second run of
pip-compile
:Where does
pip-compile
get the earlier hash from ?How can I configure
pip-compile
to really compile dependencies from scratch ?Why does
--rebuild
still reuse pre-existing hashes when those hashes are absent from anyrequirements.in
orrequirements.txt
?The text was updated successfully, but these errors were encountered: