poetry mishandles black dependencies when installed from private repository, but not when installed from PyPI #9318
Comments
blthayer
added
kind/bug
|
Exact same issue here, except on Artifactory. Transitive dependencies are not detected, and the description of the top-level dependency (black, in your case) also disappear. @blthayer, can you confirm that it only happens for top-level dependencies which have Metadata-Version 2.3? As you can see here, I get description and transitive dependencies for FastAPI right up to the moment the Metadata-Version changes from 2.1 to 2.3: |
|
@danhje - you might be on to something: bthayer@gazelle:~/black-poetry-pypi$ cat /home/bthayer/.cache/pypoetry/virtualenvs/black-poetry-pypi-1ymJqJbJ-py3.11/lib/python3.11/site-packages/black-24.4.0.dist-info/METADATA | grep Metadata-Version
Metadata-Version: 2.3
bthayer@gazelle:~/black-poetry-pypi$ nano pyproject.toml
bthayer@gazelle:~/black-poetry-pypi$ poetry update
Updating dependencies
Resolving dependencies... (2.6s)
Package operations: 5 installs, 1 update, 0 removals
- Installing click (8.1.7)
- Installing mypy-extensions (1.0.0)
- Installing packaging (24.0)
- Installing pathspec (0.12.1)
- Installing platformdirs (4.2.0)
- Downgrading black (24.4.0 -> 24.3.0)
Writing lock file
bthayer@gazelle:~/black-poetry-pypi$ cat /home/bthayer/.cache/pypoetry/virtualenvs/black-poetry-pypi-1ymJqJbJ-py3.11/lib/python3.11/site-packages/black-24.3.0.dist-info/METADATA | grep Metadata-Version
Metadata-Version: 2.1
bthayer@gazelle:~/black-poetry-pypi$
|
|
I think this might explode, as more and more packages are published with gh-action-pypi-publish v.1.8.13 or higher, which sets metadata-version to 2.3. |
|
I'm having the same problem with poetry version 1.7.1 and when trying to install openai from a private repository. the suggested solution of fixing it to "<1.21.2" solved this for me and I was able to get its dependencies. when I removed the private repository, it was working fine. Updating poetry pkginfo to 1.10 and clearing the cache solved the issue for me. |
|
@dimbleby - thanks for providing those other issues. To summarize the resolution for others that come across this issue, see this comment. To summarize, assuming installation via the $ poetry self add pkginfo>=1.10.0
$ poetry cache list
...
$ poetry cache clear PyPI --all
$ poetry cache clear ca --all
$ poetry update
...
$ # click and other dependencies now get picked up for black 24.4.0 when installing from AWS CodeArtifactOthers suggested using Does anybody have an idea or a source/reference of when the next |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Description
TL;DR
The latest
blackrelease (24.4.0) is handled properly bypoetrywhen installed from PyPI. When installed from a private repository (AWS CodeArtifact) which mirrors PyPI for non-internal-to-my-company packages,blackversion24.4.0is installed without its dependencies. Installing previous versions ofblackfrom CodeArtifact work fine.I have verified the hashes for the wheels in CodeArtifact and PyPI are IDENTICAL
Additionally, I have not encountered this issue for any package other than
blackat24.4.0. This leads me to believe the root cause of this issue stems from a combination of this newblackrelease andpoetry's handling of non-PyPI repositories.edit: As can be seen in this comment and this comment, this might be related to
Metadata-Versionchanges from2.1to2.3Evidence
Installation from PyPI Works Fine
The resulting
poetry.lockfile:Installation from AWS CodeArtifact Does Not Specify
black's Dependencies for24.4.0Building on the previous section, define the CodeArtifact repository in
pyproject.tomllike so:(URL above has been modified so as to avoid publicly exposing private information)
Now, update
poetry.lockaccordingly for new repository (authenticatingpoetrywith AWS CA not shown here - this is working fine and unrelated to the issue at hand):Unsurprisingly,
blackis now broken due to missing dependencies:Sure enough, if we inspect
poetry.lock, we see no dependencies forblack:Notice the hashes for my system's wheel are identical from the previous section. From the
poetry.lockfile that used PyPI:{file = "black-24.4.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:5cd5b4f76056cecce3e69b0d4c228326d2595f506797f40b9233424e2524c070"},From the
poetry.lockfile that used AWS CodeArtifact:{file = "black-24.4.0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hash = "sha256:5cd5b4f76056cecce3e69b0d4c228326d2595f506797f40b9233424e2524c070"},So the wheels are IDENTICAL, but
poetryis handling the one source from CodeArtifact differently than the one sourced from PyPIInstalling an Older Version of
blackfrom AWS CodeArtifact Works FineBuilding on the previous section with the CodeArtifact source (
name = "ca") inpyproject.toml, update the entry forblackfromblack = "24.4.0"toblack = "<24.4.0"and update:Workarounds
For my special use-case of installing
blackfrom private AWS CodeArtifact repository, useblack = "<24.4.0"inpyproject.tomlPoetry Installation Method
install.python-poetry.org
Operating System
Pop!_OS 22.04 LTS
Poetry Version
Poetry (version 1.8.2)
Poetry Configuration
Python Sysconfig
Example pyproject.toml
See Description - reproducing this issue involves multiple pyproject.toml iterations.Poetry Runtime Logs
The text was updated successfully, but these errors were encountered: