-
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
Package installation fail during parallel poetry runs #7370
Comments
I'd be inclined to call this a great success - I'm pretty sure that in previous releases the two poetrys would have trampled over each other and left a corrupt copy of the wheel in place so that future attempts would all fail. A one-time failure, with a more-or-less sensible error message, is really not so bad. |
Ah, Windows. I wonder if we can open files in the cache with the ability to overwrite, or simple consider a PermissionError here to be a success/use the existing file? Indeed, this is a big win, and things just /work/ on Unix, so this is a tiny edge case that shows the fix was good. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Re overwrite - note, that cached package during this situation is actively used and being installed to one of the virtualenvs. Some forced overwriting could cause that other instance to fail instead |
Right, but files opened with FILE_SHARE_DELETE should remain open as far as the process that is holding the lock is concerned, while allowing us to replace the file on disk. This would result in the same behavior as on a Unix system -- the process reading the file completes its operation (as the open file handle is retained and becomes anonymous) and the file is replaced on disk from the perspective of the other processes. Some details at https://devblogs.microsoft.com/oldnewthing/20211022-00/?p=105822. It's been a while since I've had to mess with Windows filesystem semantics, but if I'm not mistaken, setting the share flag should get us the behavior we want -- the catch here being this will require #6205 as I don't think we can control what mode pip uses to open files here. |
The chat is a bit older, but I faced the same problem. In case several processes need to access poetry you need to setup the cache dir dynamically. Poetry offers two way: either by using environment variables or by poetry config. Both act system wide so that all processes are configured the same. But the option can be put in poetry.toml. And since I needed the path dynamically I found the following option:
|
see python-poetry/poetry#7370 commit 2ee412f Author: Gerit Wagner <[email protected]> Date: Fri Jul 26 08:16:58 2024 +0200 try runner.temp with env commit 1f92ed7 Author: Gerit Wagner <[email protected]> Date: Fri Jul 26 08:08:59 2024 +0200 try POETRY_CACHE_DIR commit fc4982b Author: Gerit Wagner <[email protected]> Date: Fri Jul 26 08:03:40 2024 +0200 update cache dir commit e53e6f4 Author: Gerit Wagner <[email protected]> Date: Fri Jul 26 07:56:05 2024 +0200 set poetry cache directory
Poetry uses a cache for packages to speed up installation of the venv. It seems like the primitives it uses for that are causing issues when running multiple instances of poetry in parallel that are installing the same packages. This seems to happen only on Windows. Make these tests run sequentially on Windows to avoid this test flakyness. There's an upstream issue for poetry as well (python-poetry/poetry#7370)
Poetry uses a cache for packages to speed up installation of the venv. It seems like the primitives it uses for that are causing issues when running multiple instances of poetry in parallel that are installing the same packages. This seems to happen only on Windows. Make these tests run sequentially on Windows to avoid this test flakyness. There's an upstream issue for poetry that describes this as well (python-poetry/poetry#7370) #17183
Poetry version: 1.3.2-->
Python version: 3.9.7 -->
OS version and name: Microsoft Windows 10 Pro 10.0.19044 N/A Build 19044
pyproject.toml: toml and lock file
I am on the latest stable Poetry version, installed using a recommended method.
I have searched the issues of this repo and believe that this is not a duplicate.
I have consulted the FAQ and blog for any relevant entries or release notes.
If an exception occurs when executing a command, I executed it again in debug mode (
-vvv
option) and have included the output below.Issue
Package installation during multiple simultaneous runs of poetry install (also happens with add).
Way to reproduce
0/ copy toml and lock file from gist into two separate folders (e.g. A and B)
1/ clean up the cache, in the example shown above deleteing
d:\shared_home\poetry_cache\artifacts\0a\68\9f\8998c481b6d80d6d27eabc63ee35e31620a651b9d4f8c71044164af253\tensorflow-2.5.1-cp39-cp39-win_amd64.whl
is sufficient2/ in both folders execute poetry install -vvv almost simultaneously
3/ one of the poetry instances will install tensorflow successfully (e.g. A), one will fail (e.g. B)
Pure speculation: Maybe when package is not in the cache, each instance of poetry downloads it individually to a tempfile. The one that finishes first then renames it to proper name in this case
2.5.1-cp39-cp39-win_amd64.whl
. The slower one tries to do it as well, but the destination file already exists and thus fails?Issue is easily reproducible on the tensorflow package, most likely because it is half gig and it is thus quite probable that the poetry instances will "meet" on that one
Output of the failed one
The text was updated successfully, but these errors were encountered: