'_CountedFileLock' object has no attribute 'thread_safe'

[gaborbernat]

This (via the 3.15.0 release) may be responsible for breaking virtualenv. See pypa/virtualenv#2735.

Originally posted by @tamird in #334 (comment)

[crgwbr]

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'

[gaborbernat]

cc @ethanbb

[chrisrossi]

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.

[tamird]

@gaborbernat seems like an immediate yank would be good.

[CNDW]

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

[jfoxtech]

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'

[gaborbernat]

[vasiminamdar]

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)

[NickDunkman]

Thanks @gaborbernat!

[conradogarciaberrotaran]

Any way to force poetry to use filelock 3.14.0?

[johnthagen]

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.

[jfoxtech]

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

[conradogarciaberrotaran]

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

[cheginit]

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.

[gaborbernat]

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.

[fattybenji]

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'

[Czaki]

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

[prescod]

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.

[prescod]

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.

[Czaki]

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

[nils-borrmann-tacto]

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

[alex-pope-l3]

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

[hanssl]

Why hasn't 3.15.1 been yanked?

[ethanbb]

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.

[ethanbb]

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

[hanssl]

[hanssl]

[gaborbernat]

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

[ethanbb]

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.

[hanssl]

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

[hanssl]

filelock 3.15.3 still broken

[kwist-sgr]

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

[hanssl]

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

[johnthagen]

@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

• Ship Poetry releases with pinned dependencies 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.