'_CountedFileLock' object has no attribute 'thread_safe'
gaborbernat opened this issue · comments
This (via the 3.15.0 release) may be responsible for breaking virtualenv. See pypa/virtualenv#2735.
Originally posted by @tamird in #334 (comment)
Happening to me too. Stacktrace:
An unexpected error has occurred: CalledProcessError: command: ('/usr/local/bin/python', '-mvirtualenv', '<FOOO>/.cache/pre-commit/repou424sxk0/py_env-python3.12')
return code: 1
stdout:
RuntimeError: failed to build image pip because:
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/virtualenv/seed/embed/via_app_data/via_app_data.py", line 54, in _install
with parent.non_reentrant_lock_for_key(wheel_img.name):
File "/usr/local/lib/python3.12/contextlib.py", line 137, in __enter__
return next(self.gen)
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/virtualenv/util/lock.py", line 142, in non_reentrant_lock_for_key
with _CountedFileLock(str(self.path / f"{name}.lock")):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/virtualenv/util/lock.py", line 22, in __init__
super().__init__(lock_file)
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
stderr:
Exception ignored in: <function BaseFileLock.__del__ at 0x77ffd0526ac0>
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/filelock/_api.py", line 365, in __del__
self.release(force=True)
File "/usr/local/lib/python3.12/site-packages/virtualenv/util/lock.py", line 34, in release
with self.thread_safe:
^^^^^^^^^^^^^^^^
AttributeError: '_CountedFileLock' object has no attribute 'thread_safe'
cc @ethanbb
I just encountered this using nox on a project:
TypeError: object.__init__() takes exactly one argument (the instance to initialize)
Exception ignored in: <function BaseFileLock.__del__ at 0x7f49d3407250>
Traceback (most recent call last):
File "/home/chris/.virtualenvs/dclimate/lib/python3.10/site-packages/filelock/_api.py", line 365, in __del__
self.release(force=True)
File "/home/chris/.virtualenvs/dclimate/lib/python3.10/site-packages/virtualenv/util/lock.py", line 34, in release
with self.thread_safe:
AttributeError: '_CountedFileLock' object has no attribute 'thread_safe'
Started whenever 3.15 hit pypi.
@gaborbernat seems like an immediate yank would be good.
happening to me as well, all of our builds in CI stopped building with this error -> the virtualenv package depends on this one so I suspect this is a very widespread failure.
I've been seeing it on python 3.11.9
Also encountering when trying to spin up a venv via poetry:
Exception ignored in: <function BaseFileLock.__del__ at 0x7fc53764b6d0>
Traceback (most recent call last):
File "/home/runner/.local/venv/lib/python3.10/site-packages/filelock/_api.py", line 365, in __del__
self.release(force=True)
File "/home/runner/.local/venv/lib/python3.10/site-packages/virtualenv/util/lock.py", line 34, in release
with self.thread_safe:
AttributeError: '_CountedFileLock' object has no attribute 'thread_safe'
Below traceback running virtualenv venv
Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/virtualenv/seed/embed/via_app_data/via_app_data.py", line 54, in _install with parent.non_reentrant_lock_for_key(wheel_img.name): File "/usr/local/lib/python3.9/contextlib.py", line 119, in __enter__ return next(self.gen) File "/usr/local/lib/python3.9/site-packages/virtualenv/util/lock.py", line 1[42](https://gitlab.com/ftdr/devops/tools/deployinator/-/jobs/7085218033#L42), in non_reentrant_lock_for_key with _CountedFileLock(str(self.path / f"{name}.lock")): File "/usr/local/lib/python3.9/site-packages/virtualenv/util/lock.py", line 22, in __init__ super().__init__(lock_file) TypeError: object.__init__() takes exactly one argument (the instance to initialize)
Thanks @gaborbernat!
Any way to force poetry to use filelock 3.14.0?
Now that filelock 3.15.0 is yanked, any bare installs of pip install poetry==N will no longer select filelock 3.15.0 as a sub dependency. Our CI is working again.
@conradogarciaberrotaran See above, as I already tried that path. All is well now on my end as well!
Re-running fixed everything! I was worried our cache would still use 3.15.0 but it's not the case.
Just wanted to let you know that v3.15 still exists on conda-forge, so envs that are created with conda will fail due to this error.
Just wanted to let you know that v3.15 still exists on
conda-forge, so envs that are created withcondawill fail due to this error.
I do not control conda, so that will be fixed by someone else.
This issue happens again with version 3.15.2 in my CI. Context: creating a virtualenv with poetry by running poetry install. Python 3.12. Full stack below. Should I open a new issue ?
Creating virtualenv lambda-functions-P30EH11U-py3.12 in /root/.cache/pypoetry/virtualenvs
Exception ignored in: <function BaseFileLock.__del__ at 0xf23383f01da0>
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/filelock/_api.py", line 388, in __del__
self.release(force=True)
File "/usr/local/lib/python3.12/site-packages/virtualenv/util/lock.py", line 34, in release
with self.thread_safe:
^^^^^^^^^^^^^^^^
AttributeError: '_CountedFileLock' object has no attribute 'thread_safe'
failed to build image pip because:
Traceback (most recent call last):
File "/usr/local/lib/python3.12/site-packages/virtualenv/seed/embed/via_app_data/via_app_data.py", line 54, in _install
with parent.non_reentrant_lock_for_key(wheel_img.name):
File "/usr/local/lib/python3.12/contextlib.py", line 137, in __enter__
return next(self.gen)
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/virtualenv/util/lock.py", line 142, in non_reentrant_lock_for_key
with _CountedFileLock(str(self.path / f"{name}.lock")):
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/filelock/_api.py", line 117, in __call__
instance = super().__call__(
^^^^^^^^^^^^^^^^^
TypeError: _CountedFileLock.__init__() got an unexpected keyword argument 'timeout'
Your error is caused by filelock 3.15.2 release that already is yanked from pypi https://pypi.org/project/filelock/#history
Yes, something strange is happening in github or Poetry or something. Somehow in the last hour its started picking up the yanked version of filelock. :( I know there is nothing the filelock maintainers can do about it, but this is the only context to discuss it which Google will turn up for people.
Poetry has not had a release. virtualenv has not had a release. I don't know what project is picking up the yanked version of filelock.
Problematic version is released 34 minutes ago, and yanked few minutes later
Fyi: I also experienced this issue on the (non-yanked) release 3.15.1. Downgrading to 3.14.0 helped.
We also had breakages due to version 3.15.2. Downgrading to 3.14.0 fixed the problem for us too.
Why hasn't 3.15.1 been yanked?
Can someone post an error they got from 3.15.1? I don't believe it could be the same problem....changes in the last release (3.15.2) clearly created the new issue, which is different from the one in 3.15.0.
This issue happens again with version 3.15.2 in my CI. Context: creating a virtualenv with poetry by running poetry install. Python 3.12. Full stack below. Should I open a new issue ?
It's a different error, so probably yes
Please provide version information via pip of the packages installed. That doesn't look like 3.15.1.
Yes looks like your code is still using 3.15.2. The code producing the error didn't exist when 3.15.1 was released.
You are correct, I am on a mirrored pypi that is still pulling in 3.15.2 to my poetry environments.
filelock 3.15.3 still broken
@hanssl This isn't like 3.15.3.
stack trace is the same as here #337 (comment)
@hanssl This isn't like 3.15.3. stack trace is the same as here #337 (comment)
Maybe I am missing something? I deleted my poetry venv, created a new one, and ran poetry install (verified the 'Installing filelock (3.15.3) line). I then run 'docker build...' from that poetry env and I got the error above.
@hanssl You might have an old/broken filelock installed into Poetry's internal virtual environment. You may need to uninstall Poetry and reinstall it so that it picks a non-yanked filelock when Poetry itself is installed.
Note, this kind of issue is why a while ago I opened
So that it would not be possible for Poetry users to install Poetry with dependencies it hadn't tested/validated in its CI.