AssertionError from Poetry install #6788
Comments
jace-ys
added
kind/bug
|
suggest submit an MR that copes with even better if you can figure out how to reproduce in unit test... |
Hey @dimbleby, thanks for your suggestion. Are you suggesting that what I'm seeing is due to some bug in the Poetry installer that doesn't properly handle |
|
clearly poetry doesn't handle I don't understand any better than you what are the circumstances where that happens but it seems straightforward and pragmatic to cope with it. |
|
|
|
Interesting, that's useful to know. I can't seem to figure out the exact circumstance to reproduce the issue consistently, but I can say for certain that I'm not encountering it locally but only on my production build environment 😞 It's also interesting that no one else has reported this issue before, so I'm wondering if it's something specific to my environment 🤔 |
|
Incidentally, this is why typing assertions are so powerful/preferable to cast -- if the assert wasn't there, we likely would have failed in a different and more exotic/hard to debug way. I was unable to reproduce on Linux/amd64 using your pyproject.toml (dropping |
|
I would say it has been mostly intermittent (~30% of the time), but for unknown reasons it's occurring a lot more regularly these past two days 😭 I have a slight hunch on what could be the cause but I'd need some time to verify it. Hunch being some egress rules in my production environment blocking certain traffic when installing dependencies, so |
|
Tiny update: we discovered that the We are not super sure what's causing the original dependency to be deleted and will look into it more tomorrow. We suspected it might be a race condition somewhere where a thread deletes the original dependency before it can be updated, but even running with As for why it only happens on our build environment and not locally, we're still looking into that. |
|
If I were you I'd just submit an MR and be done with it... |
Thanks for the suggestion @dimbleby, I can give that a go soon if we're all agreed that that's the right approach. Just want to share a bit more findings that maybe you folks could help demystify: When performing an update, it seems like the Other than dropping the assertions, another workaround we found was setting I don't think there's a whole lot more we can find, so we will probably settle for setting @dimbleby @neersighted Any thoughts or ideas? |
|
Dropping the new installer is not a good idea -- you are falling back to pip fetching packages, instead of Poetry, which is not nearly as tested and which is going to be removed soon. I would instead experiment with limiting parallelism with Given we already handle the case of |
Thanks @neersighted. I don't think it's a race condition as I've tried both I will raise a PR to handle |
|
Raised a PR here: #6877. Let me know what you folks think! 😄 |
|
I had a failure similar to this, I believe the issue was caused by changing the repository URL. GitLab CI/CD was using Poetry 1.2.2 to build a test environment. Previously a couple versions of the package had been built by GitLab. The repository URL was changed slightly and then another package was attempted to be created. Here is the log snippet of the test failing to create the Poetry environment: where {repository} is the name of the updated repository. I tried running the build multiple times and it always failed. After reverting to the old repository name the build was able to succeed. I think it was trying to reference a cache that did not exist and so was None and failed. |
|
Me too Writing lock file
Package operations: 326 installs, 2 updates, 0 removals
• Installing attrs (22.1.0): Failed
AssertionError
at ~/.local/share/pypoetry/venv/lib/python3.10/site-packages/poetry/utils/env.py:343 in find_distribution_files_with_name
339│ ) -> Iterable[Path]:
340│ for distribution in self.distributions(
341│ name=distribution_name, writable_only=writable_only
342│ ):
→ 343│ assert distribution.files is not None
344│ for file in distribution.files:
345│ if file.name == name:
346│ yield Path(
347│ distribution.locate_file(file), # type: ignore[no-untyped-call] |
We discovered that in some unknown situations, `distribution.files` can be `None`, causing the assertion to fail. To handle `distribution.files` being `None` more gracefully, we treat it as if it were an empty list. Resolves: #6788
|
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. |
-vvvoption) and have included the output below.Issue
Hey 👋🏻
I have a Docker image which runs
poetry installand this works completely fine on my local machine (M1 MacBook) but for some reason fails occasionally on my production build pipeline (running on Linux x86_64). I can't seem to figure out why it's happening, so was wondering if anyone here might have an idea?Dockerfile:
Stack trace from
poetry install -vvv:The text was updated successfully, but these errors were encountered: