'_CountedFileLock' object has no attribute 'thread_safe'

Question

'_CountedFileLock' object has no attribute 'thread_safe'

gaborbernat opened this issue 5 months ago · 34 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)

Answer 1 · 2024-06-12T18:30:02.000Z

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'

Answer 2 · 2024-06-12T18:32:39.000Z

cc @ethanbb

Answer 3 · 2024-06-12T18:34:44.000Z

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.

Answer 4 · 2024-06-12T18:37:01.000Z

@gaborbernat seems like an immediate yank would be good.

Answer 5 · 2024-06-12T18:37:20.000Z

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

Answer 6 · 2024-06-12T18:41:35.000Z

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'

Answer 7 · 2024-06-12T18:43:08.000Z

gaborbernat commented 5 months ago

❤️30

Answer 8 · 2024-06-12T18:43:10.000Z

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)

Answer 9 · 2024-06-12T18:43:40.000Z

Thanks @gaborbernat!

Answer 10 · 2024-06-12T18:46:54.000Z

Any way to force poetry to use filelock 3.14.0?

Answer 11 · 2024-06-12T18:48:47.000Z

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.

Answer 12 · 2024-06-12T18:52:29.000Z

@conradogarciaberrotaran See above, as I already tried that path. All is well now on my end as well!

Answer 13 · 2024-06-12T18:53:05.000Z

Re-running fixed everything! I was worried our cache would still use 3.15.0 but it's not the case.

Answer 14 · 2024-06-13T02:17:47.000Z

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.

Answer 15 · 2024-06-13T02:20:38.000Z

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.

I do not control conda, so that will be fixed by someone else.

Answer 16 · 2024-06-19T14:22:35.000Z

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'

Answer 17 · 2024-06-19T14:23:21.000Z

Your error is caused by filelock 3.15.2 release that already is yanked from pypi https://pypi.org/project/filelock/#history

Answer 18 · 2024-06-19T14:37:54.000Z

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.

Answer 19 · 2024-06-19T14:40:09.000Z

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.

Answer 20 · 2024-06-19T14:47:34.000Z

Problematic version is released 34 minutes ago, and yanked few minutes later

Answer 21 · 2024-06-19T15:15:13.000Z

Fyi: I also experienced this issue on the (non-yanked) release 3.15.1. Downgrading to 3.14.0 helped.

Answer 22 · 2024-06-19T15:18:08.000Z

We also had breakages due to version 3.15.2. Downgrading to 3.14.0 fixed the problem for us too.

Answer 23 · 2024-06-19T15:26:40.000Z

Why hasn't 3.15.1 been yanked?

Answer 24 · 2024-06-19T15:27:53.000Z

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.

Answer 25 · 2024-06-19T15:31:47.000Z

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

Answer 26 · 2024-06-19T15:32:11.000Z

hanssl commented 5 months ago

Answer 27 · 2024-06-19T15:33:55.000Z

hanssl commented 5 months ago

Answer 28 · 2024-06-19T15:34:03.000Z

Please provide version information via pip of the packages installed. That doesn't look like 3.15.1.

Answer 29 · 2024-06-19T15:35:10.000Z

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.

Answer 30 · 2024-06-19T15:41:32.000Z

You are correct, I am on a mirrored pypi that is still pulling in 3.15.2 to my poetry environments.

Answer 31 · 2024-06-19T16:43:24.000Z

filelock 3.15.3 still broken

Answer 32 · 2024-06-19T16:46:57.000Z

@hanssl This isn't like 3.15.3.
stack trace is the same as here #337 (comment)

Answer 33 · 2024-06-19T16:56:27.000Z

@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.

Answer 34 · 2024-06-20T10:58:46.000Z

@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

python-poetry/poetry#7990

So that it would not be possible for Poetry users to install Poetry with dependencies it hadn't tested/validated in its CI.