-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Poetry now does not add the package.dependencies #7961
Comments
I use private dependencies and repositories, and poetry 1.5.0 works fine without a way to reproduce this there's not going to be very much that anyone can do. |
We use poetry inside docker. The image we use is |
Also seeing the same behavior on Poetry 1.5.0, Python 3.9+. We have several Python packages hosted in a private repo, and when trying to add them to a new project with Also noticed as well that the descriptions of our private packages are now empty in our 'new project' lock files. I have my sources defined as follows, if it helps. [[tool.poetry.source]]
name = "private_pypi"
url = "https://pypi.domain.tld/simple/"
priority = "supplemental"
[[tool.poetry.source]]
name = "PyPI"
priority = "primary" Edit: I created a simple project to reproduce the issue. See https://github.com/cquick01/cq-test-poetry When adding to a separate project with
Pip freeze shows only one package installed.
However, if installing with
|
Works fine for me using
[tool.poetry.dependencies]
python = "^3.10"
[[tool.poetry.source]]
name = "private_pypi"
url = "http://localhost:8080/simple/"
priority = "supplemental"
[[tool.poetry.source]]
name = "PyPI"
priority = "primary"
|
Try with
pyproject.toml (from new project we're trying to install cq-test-poetry into)
And trying to add the package fails to install dependencies with poetry, but pip works fine.
|
That also works just fine for me |
So I tried to repro in docker, but was unable to. After messing with it a bit more, it appears that deleting I have that cache directory backed up just in case. If there is any specific info that might be useful, I can look for it. I'd rather not just post the whole dir up somewhere because I don't know if any private info, like my company packages, are within. It'd be good to avoid putting users into a weird state like this if poetry could detect and clean up the problematic cache. But for now this gets things working again. Thanks! |
I was struggling with not getting the dependencies installed today when upgrading to Poetry 1.5.0 and python 3.10.11. The original [tool.poetry.dependencies]
python = "^3.10"
[[tool.poetry.source]]
name = "private_pypi"
url = "http://localhost:8080/simple/"
priority = "primary" However, when I modified it to include PyPI like this then the dependencies arrived: [tool.poetry.dependencies]
python = "^3.10"
[[tool.poetry.source]]
name = "private_pypi"
url = "http://localhost:8080/simple/"
priority = "supplemental"
[[tool.poetry.source]]
name = "PyPI"
priority = "primary" This means that I'm no longer using my pull-through cache to get the set of packages. However, it works for now so I can move forward. Was there some change that causes this behavior? I'm thinking its related to this ticket too since the behavior seems similar. |
And is your case also resolved by clearing your poetry cache? |
We're back to: please provide a way to reproduce. (So far the only reproducer that we've seen is resolved by clearing the cache) |
I'm sort of able to reproduce this again, this time in docker. The entirety of Fails to find deps:
Finds deps with
Installing from
I've updated https://github.com/cquick01/cq-test-poetry with a Dockerfile, hopefully others can reproduce too now... |
@cquick01 once again this works just fine for me. you keep using Then, as before, |
Our real pypi server is not accessible from the outside world. Here, I've setup a VPS with an nginx server hosting the package at http://ec2-18-219-190-206.us-east-2.compute.amazonaws.com/simple/ (probably offline now) And trying to install
And
Can you send me a public key and I'll just give you access to the instance? |
I apologize that this took me a while to get back to and reproduce related to my bug report above. I did in fact find that clearing my entire poetry cache did the trick. There did not appear to be another way for it to work with my devpi service as the
Just to be sure this worked I did this for several repos I'm in the process of upgrading and was able to reproduce that clearing the cache works for them as well. I was upgrading from 1.3.2 to 1.5.0 in case other folks are curious.. Thanks again for the hard work you put into this repository and issues like this. I know its not always great dealing with user reports. |
We are also running an issue that looks like this with our internal registry and Poetry 1.5. I think I've narrowed it down to some kind of issue with response caching, because if we disable Etags on our PyPI registry, the issues go away. It's been tricky to reproduce this but I've managed to create two small publicly accessible reproduction indexes which have Here is a test [tool.poetry]
name = "test-project"
version = "0.0.0"
authors = []
description = ""
[tool.poetry.dependencies]
python = "^3.11"
boto3 = "1.26.137"
[[tool.poetry.source]]
name = "my-pypi"
url = "https://ckuehl.me/tmp/poetry-7961/simple"
# Switch to this URL to test without etags:
# url = "https://ckuehl.me/tmp/poetry-7961/simple-no-etags"
priority = "default"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api" When installing from the first repo, only Output with the first registry (Etags enabled)
Output with the second registry (Etags disabled)
I'm still trying to figure out exactly what happens; the problem may not be Etags themselves but just that they enable the caching logic which causes the issue. I'm continuing to look into this but since there has been a lot of searching for reproductions I figured I would post this sooner rather than later. |
@ralbertazzi looks like this was introduced at #7916 I think the problem is that the the cached file returned by |
@dimbleby I just came to the same conclusion. Here's a (very rough/awkward, probably not what we want to merge) patch which fixes it for me: diff --git a/src/poetry/repositories/http_repository.py b/src/poetry/repositories/http_repository.py
index ae96481a..88977d69 100644
--- a/src/poetry/repositories/http_repository.py
+++ b/src/poetry/repositories/http_repository.py
@@ -78,7 +78,14 @@ class HTTPRepository(CachedRepository):
def _cached_or_downloaded_file(self, link: Link) -> Iterator[Path]:
filepath = self._authenticator.get_cached_file_for_url(link.url)
if filepath:
- yield filepath
+ import os
+ from cachecontrol.serialize import Serializer
+ serializer = Serializer()
+ with temporary_directory() as temp_dir:
+ path = os.path.join(temp_dir, "wheel.whl")
+ with open(path, "wb") as f:
+ f.write(serializer.loads(None, open(filepath, "rb").read()).data)
+ yield path
else:
self._log(f"Downloading: {link.url}", level="debug")
with temporary_directory() as temp_dir: Even though this is not a good patch, maybe other people experiencing this could also test it to verify if it's the same root cause for all these reports? |
Can confirm disabling etags in nginx.conf fixes it for me. I'll try testing with that patch. Thanks guys! Edit: yes, that patch works for me with etags enabled!
|
Not sure if this is related to a bug under psf/cachecontrol#292 or not, but I set |
I don't think #7916 made a lot of sense. As this MR shows, the file that is being inspected is an internal implementation detail for cachecontrol. The suggested patch above, deserializing the file, is presumably doing only what cachecontrol would have done all along. If poetry repeats a GET that cachecontrol has already seen, cachecontrol can take care of that. |
I'll check myself but it seems like the best solution is to revert the change. @dimbleby do you have suggestions on how to best deal with the buffer size when the file is already cached locally? We use a |
in the long run I think the right fix is probably not to use cachecontrol at all for package distributions - we have an I don't know any particularly good reason for the chunk size to be so small even when downloading from the internet, though I don't know whether this is a change that would be accepted in - I assume - an upcoming patch release. |
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. |
Issue
I was using the poetry version 1.4.2, when adding a new package from a private pypi it adds also the package dependencies well as you can see here: (I remove the private values, but I promise that are the same for the other example)
When using poetry version 1.5.0, for the same package, poetry did not added the dependencies, also the description was not added and the python version not specified:
So in that case for us this is not a minor update, this is a major update as it is breaking some of our dependencies.
The text was updated successfully, but these errors were encountered: