-
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
No such file or directory due to race condition #8159
Comments
then please close as such! This repository already has far more open issues than anyone can keep up with: scattering discussion of duplicates across multiple places does not help. It also leave a much messier trail for the next person who hits something similar, it becomes much harder for them to find whatever useful discussion there is. |
@dimbleby well given this one narrows down the possible cause of the issue, and refers to a more recent version of poetry, perhaps we should close the other one instead? |
and then next time someone makes further progress, close this one in favour of that? this seems to me silly let's just have the discussion in the open issue that already tracks the problem |
And update that issue to state it happens on 1.5.1 too? Is there not a risk that ticket will get closed because it points to an old version? |
Actually 6958 talks about a different use case. I'll update my ticket to state it's not a duplicate. We have been encountering this error for a long time, and only just recently figured out it likely relates to concurrency, and are now able to demonstrate the behaviour on a recent version of poetry. This ticket should absolutely not be closed (unless we find an exact duplicate ) - no matter how many open issues this project is being overloaded with. |
I have been reading through the source code to understand what's going on in more detail. Would I be correct in thinking that what happens is:
I think the only way to avoid this situation would be for poetry to determine that pip was going to try to access package A as part of the operation on package B, and therefore not to allow these two operations to run in parallel. My understanding was that poetry already does this by searching for the deepest dependency, but my guess is that serial installs perhaps hide some of the subtleties of this strategy, and parallel installs occasionally get caught short. I'm thinking:
I briefly looked at the puzzle code but couldn't figure out how it works. |
per your stack, the error is happening while shelling out to it looks as though (Upgrading a package requires first uninstalling the old version: so it's not only pure uninstalls) ideally it's desirable not to shell out to pip here at all - poetry's modern installer shells out to pip only when uninstalling packages - but to have some in-process uninstaller, and for that not to care about packages B, C, D etc while it is uninstalling A pragmatically I expect you should prefer simply to disable parallelism in your CI |
Agree with all the above. We'll disable parallel installs on CI. Do we know roughly what performance hit to expect from doing so? I measured locally and it's barely 15% slower across several runs, but then again I have everything in cache, which CI won't. |
I'm hitting frequent failures upon parallel The stack trace looks completely different from what what discussed in this and the related tickets (ends up in pip at I can reliably reproduce it on my machine with Ubuntu 20.04 and Python 3.11 from Anaconda, but none of my colleagues has complained so far. Any ideas (other than disabling parallel installation altogether?)
|
We are also facing the same exact issue in our github CI environment. We are using the latest poetry version 1.7.1.
|
Still happens in 1.8.2 poetry |
-vvv
option) and have included the output below.This is similar to6958 but is not a duplicate as its a different use case.
This was happening for us on 1.3.1 and previous versions too.
Issue
Poetry fails to either install or upgrade a package (in this case setuptools) because it fails to find the .dist-info directory of another package (in this case proto_plus-1.22.2.dist-info) and that's because that package was upgraded from 1.22.2 to 1.22.3 just before (see output) but I suspect that operation didn't update the register in time.
In this case it's the pip uninstall which fails:
(copied from output below)
But the same issue can happen with a pip install too:
(taken from a different run that failed)
Re-running the job usually works, but it can fail on other packages or other projects in the job. This happens on maybe 1 out of 50-100 installs, but seeing we have 30+ projects/installs per job, jobs as a whole fail quite frequently. This has been happening on and off for well over a year, but weirdly it started happening with increasing frequency lately (on 1.3.1) and we just updated to 1.5.1 hoping it might resolve but to no avail.
There is no change to our CI environment that we are aware of (but it could even be a network change causing some packages to install much faster than before/on some occasions). We have no record of this happening locally but that could be down to number of installs.
I suspect this is related to the race condition fixed by 6186 and suspect that if we switch off parallel installations that fixes it.
The output below is from a private runner for github CI, and the command is running against a docker container.
The text was updated successfully, but these errors were encountered: