Acquiring locks fails on GraalPy 25.0.1 #462
Description
While running tests against GraalPy 25.0.1 on an ubuntu-22.04 runner on GitHub Actions, I've found that tox fails to acquire a file lock:
Traceback (most recent call last):
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/bin/tox", line 8, in <module>
sys.exit(run())
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/run.py", line 23, in run
result = main(sys.argv[1:] if args is None else args)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/run.py", line 49, in main
return handler(state)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/cmd/legacy.py", line 115, in legacy
return run_sequential(state)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/cmd/run/sequential.py", line 25, in run_sequential
return execute(state, max_workers=1, has_spinner=False, live=True)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/cmd/run/common.py", line 169, in execute
state.envs.ensure_only_run_env_is_active()
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/env_select.py", line 437, in ensure_only_run_env_is_active
envs, active = self._defined_envs, self._env_name_to_active()
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/env_select.py", line 292, in _defined_envs
raise failed[next(iter(failed_to_create))]
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/env_select.py", line 269, in _defined_envs
run_env.package_env = self._build_pkg_env(pkg_name_type, name, env_name_to_active)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/env_select.py", line 336, in _build_pkg_env
package_tox_env = self._get_package_env(core_type, name, active.get(name, missing_active))
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/session/env_select.py", line 368, in _get_package_env
pkg_env.register_config()
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/tox_env/package.py", line 48, in _func
return meth(*args, **kwargs)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/tox_env/python/virtual_env/package/pyproject.py", line 157, in register_config
self._add_config_settings(key)
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/tox/tox_env/package.py", line 45, in _func
file_lock.acquire()
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/filelock/_api.py", line 332, in acquire
self._acquire()
File "/opt/hostedtoolcache/GraalPy/25.0.1/x64/lib/python3.12/site-packages/filelock/_unix.py", line 41, in _acquire
open_flags = os.O_RDWR | os.O_TRUNC | os.O_NOFOLLOW
AttributeError: module 'os' has no attribute 'O_NOFOLLOW'
It seems like GraalPy doesn't support O_NOFOLLOW, and per the Python docs is not guaranteed to be present in general: https://docs.python.org/3/library/os.html#os.O_NOFOLLOW
The above constants are extensions and not present if they are not defined by the C library.
Would it make sense to check whether O_NOFOLLOW is defined on os before attempting to use it?