Open antoineeudes opened 1 year ago
I updated the title to describe what is actually going on; overall I think our VCS support breaks when subdirectories or mismatched names are involved, and this may be a duplicate of an existing issue. Not sure who to ping on VCS issues, but this entire subject could use some eyes, so I'll try to bother the other maintainers about it.
This got broken with some version between 1.1.14
and 1.2.2
Maybe by introducing canonicalize_name
with 1.2.0
: https://github.com/python-poetry/poetry/issues/4770#issuecomment-1179560514
The same happens with the dash/underscore transformation/mapping:
poetry 1.1.14
# pyproject.toml
abas-erp-api-client = {git = "ssh://git@gitlab.XXXX/abas_erp_api_client.git", develop = true, rev = "main"}
$ poetry install
$ ls venv/src
abas-erp-api-client
$ poetry update
No dependencies to install or update
poetry 1.2.2
# pyproject.toml
abas-erp-api-client = {git = "ssh://git@gitlab.XXXX/abas_erp_api_client.git", develop = true, rev = "main"}
$ poetry install
$ ls venv/src
abas_erp_api_client
$ poetry update
No git repository was found at /Users/maltegerth/test-poetry-1.2.2/venv/src/abas-erp-api-client
This got broken with some version between 1.1.14 and 1.2.2
I don't think this assertion is correct per-se; mismatched names have always been an issue. We've added more features that can trigger this, and made our name handling code more robust. But I think this has always been fundamentally naive/broken, and recent changes have just increased the surface area.
Related: #6958
Here's a possible workaround for anyone else hitting this.
I ran into this while trying to upgrade from Poetry 1.1 and I found poetry install
only fails when the dependency has develop = true
. So I removed develop = true
in pyproject.toml
, manually updated develop = false
in poetry.lock
, and poetry env remove
'd the broken env. Now poetry install
works every time for Poetry 1.2+.
This does mean we can't use develop = true
. For anyone that needs to develop locally, this is definitely not ideal. But it should be fine if you're just pinning to git commits to work around release issues (like me), because you're not actually working on the dependencies locally. (I don't actually know why we committed develop = true
to our repo in the first place. Persisting a local dev flag seems like a bug. Unless I'm missing something about git deps?)
All four of these issues appear to be the same issue (AFAICT):
Of the four, this issue (#7113) seems to get to the essence of the fundamental problem, nicely summarized by @antoineeudes :
I guess there could be a confusion between the name of the library and the name of the git repository.
I would guess that this could be solved with the "Potential fix" described here: https://github.com/python-poetry/poetry/issues/7181#issuecomment-1427120155
(... but I haven't worked on Poetry, so perhaps that's naive)
I'm guessing that a significant number of users are running into this problem since there are so many different issues about it, and it likely prevents anyone from using Poetry with any sort of private git monorepos (or even just repos with more than one package).
I can't seem to reproduce it on Poetry 1.5.1. Here's my pyproject.toml
[tool.poetry]
name = "poetry-git"
version = "0.1.0"
description = ""
authors = ["Riccardo Albertazzi <foo@bar.com>"]
readme = "README.md"
packages = [{include = "poetry_git"}]
[tool.poetry.dependencies]
python = "^3.9"
# A plain simple fork of requests
requests = {git = "https://github.com/ralbertazzi/rfork.git", develop = true}
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
every command succeeds.
❯ poetry install
Creating virtualenv poetry-git in /<path-to-project>/.venv
Installing dependencies from lock file
Package operations: 5 installs, 0 updates, 0 removals
• Installing certifi (2023.5.7)
• Installing charset-normalizer (3.1.0)
• Installing idna (3.4)
• Installing urllib3 (2.0.2)
• Installing requests (2.31.0 6e5b15d)
Installing the current project: poetry-git (0.1.0)
❯ poetry update
Updating dependencies
Resolving dependencies... (1.6s)
Package operations: 0 installs, 1 update, 0 removals
• Updating requests (2.31.0 /<path-to-project>/.venv/src/rfork -> 2.31.0 6e5b15d)
❯ poetry add redis
Using version ^4.5.5 for redis
Updating dependencies
Resolving dependencies... (0.1s)
Package operations: 2 installs, 1 update, 0 removals
• Installing async-timeout (4.0.2)
• Installing redis (4.5.5)
• Updating requests (2.31.0 /<path-to-project>/.venv/src/rfork -> 2.31.0 6e5b15d)
Here's the poetry.lock
entry for reference:
[[package]]
name = "requests"
version = "2.31.0"
description = "Python HTTP for Humans."
optional = false
python-versions = ">=3.7"
files = []
develop = true
[package.dependencies]
certifi = ">=2017.4.17"
charset_normalizer = ">=2,<4"
idna = ">=2.5,<4"
urllib3 = ">=1.21.1,<3"
[package.extras]
socks = ["PySocks (>=1.5.6,!=1.5.7)"]
use-chardet-on-py3 = ["chardet (>=3.0.2,<6)"]
[package.source]
type = "git"
url = "https://github.com/ralbertazzi/rfork.git"
reference = "HEAD"
resolved_reference = "6e5b15d542a4e85945fd72066bb6cecbc3a82191"
I'd be great if you could provide a way to reproduce the issue on the latest Poetry
For doubt's sake I also tried the ssh specification and that also works:
requests = {git = "ssh://git@github.com/ralbertazzi/rfork.git", develop = true}
@ralbertazzi can you try poetry install
with this repo https://github.com/JonathanRayner/some_other_repo ? Here I have 5 packages that are each slower clones, hopefully more consistently triggering the issue.
-vvv
option) and have included the output below.Issue
Hello Poetry team!
I am trying to install a dependency from a private Gitlab repository. Let's call the repository
foo
and the librarybar
. In my pyproject.toml, I added the following line:After executing
poetry install
, I see that the library is successfully installed:But, when I try to install another dependency, I get an error:
It appears the git repository is not found in the virtual environment under the path
src/bar
. However, I can see the repo is there under the pathsrc/foo
. I guess there could be a confusion between the name of the library and the name of the git repository.Here is the complete log:
Thank you !