Installation of URL dependencies can fail on the latest virtualenv version, in certain environments ('free_threaded' AttributeError) #10056
Comments
sirosen
added
kind/bug
|
probably just a bug in the latest virtualenv, you should report it to them |
|
I don't think so, although I could be mistaken. I've read the If you look at those changes, Poetry is using |
|
virtualenv has a cache, I expect there is a cached thing somewhere that does not have the new field. You should report this to them. |
|
@sirosen I'd advice that you consider not using Unable to reproduce this. podman run --rm -i --entrypoint bash docker.io/python:3.10-slim-bookworm <<EOF
set -xe
# using pip here for simplicity (not recommended)
python -m pip install --disable-pip-version-check --root-user-action ignore -q poetry
poetry new foobar
pushd foobar
# using pre-commit as an example as it uses setup.py
poetry add https://files.pythonhosted.org/packages/2e/c8/e22c292035f1bac8b9f5237a2622305bc0304e776080b246f3df57c4ff9f/pre_commit-4.0.1.tar.gz
EOF+ poetry add https://files.pythonhosted.org/packages/2e/c8/e22c292035f1bac8b9f5237a2622305bc0304e776080b246f3df57c4ff9f/pre_commit-4.0.1.tar.gz
Creating virtualenv foobar-lWDpn5M1-py3.10 in /root/.cache/pypoetry/virtualenvs
Updating dependencies
Resolving dependencies...
Package operations: 9 installs, 0 updates, 0 removals
- Installing distlib (0.3.9)
- Installing filelock (3.16.1)
- Installing platformdirs (4.3.6)
- Installing cfgv (3.4.0)
- Installing identify (2.6.5)
- Installing nodeenv (1.9.1)
- Installing pyyaml (6.0.2)
- Installing virtualenv (20.29.0)
- Installing pre-commit (4.0.1 https://files.pythonhosted.org/packages/2e/c8/e22c292035f1bac8b9f5237a2622305bc0304e776080b246f3df57c4ff9f/pre_commit-4.0.1.tar.gz)
Writing lock file |
|
the problem will be what I already said: on the system with a problem there is a virtualenv cache that contains an object without the new field, and the updated code does not cope with that once more: this is a virtualenv bug and should be reported there |
|
dimbleby, I am sure you might be right there about the root cause. But I am definitely curious how the cache is impacting it inside a container (assuming a clean container). |
Presumably not a clean container |
|
We are getting Pinning to the previous |
|
I've been digging around and I can easily imagine that this is related to a cache load -- the virtualenv cache loading code includes a usage It is starting from a clean container -- and if I stop the build before the relevant stage where One very interesting thing I've found is that the application itself seems to depend through some chain on Fixing the lack of isolation between -RUN python -m venv .venv \
- && .venv/bin/python -m pip install 'poetry==2.0.1'
- RUN .venv/bin/poetry install
+RUN python -m venv .poetry-venv \
+ && .poetry-venv/bin/python -m pip install 'poetry==2.0.1'
+RUN .poetry-venv/bin/poetry install -vvSo I think that what's happening is that the lack of isolation causes a conflict between simultaneous invocations of multiple I now have enough data, even sans a clear reproducer (which continues to elude me), that I feel like I can bring a bug report to I leave it to the poetry devs to decide whether or not this scenario is sufficiently far outside of the bounds of what is supported that this can be closed. It seems to require that you mix your app venv with the |
|
@sirosen as described in https://python-poetry.org/docs/#installation,
@FeodorFitsner it looks like you are doing something similar as well, ie. reusing the same Python environment for both Poetry and your app. - Installing uvicorn (0.33.0)
- Downgrading virtualenv (20.29.0 -> 20.28.1)
- Installing watchdog (4.0.2)Closing as this is not a Poetry issue. |
|
Makes sense! Will re-do CI to install Poetry into separate env. Thank you guys! |
abn
removed
kind/bug
In order to avoid new issues being created for this error message, if you are here searching for the error message please see #10056 (comment) for resolution.
This issue was caused because of the following;
This is not a Poetry issue, but rather an issue caused by attempting to install Poetry in the same environment as it is managing. This is not recommended.
Description
I don't have a full reproducer yet, unfortunately. I have this bug in a closed-source context and haven't yet been able to recreate it.
Under the latest version of
virtualenv, a new attribute was added to thePythonInfoclass,free_threaded.In my org's usage, we're seeing an invocation of
virtualenv.cli_runwhich passes aPythonInfoobject wherefree_threadedis not defined, causing an AttributeError from withinvirtualenvitself.The conditions I have right now which cause this:
virtualenv==20.29.0setup.py, notpyproject.tomlHowever, trying to repro this in a fully open-source repo, I can't get the bug to trigger. So there may be important state I haven't captured.
Note
Without full info, this might not be possible to diagnose or resolve.
If the maintainers feel it would be best to close this as invalid, I'll continue to work on a reproducer so that I can open a fresh bug report with better detail.
I would understand that course of action and consider it reasonable if necessary, but hope that with the partial info in this report there's enough detail to find the cause.
Workarounds
poetry==1.8.5virtualenvin our build system to<20.29.0Poetry Installation Method
pip
Operating System
Debian (docker,
python3.10-slim-bookworm)Poetry Version
4.0.1
Poetry Configuration
(NB: this is a local run; in the build system we expect a different home, etc.)
Python Sysconfig
sysconfig.log
Example pyproject.toml
N/A: project is closed source and I don't have a working reproducer (yet).Poetry Runtime Logs
I've redacted some names from the tail end of the log. I can't share full output until I have an open source reproducer.
poetry-runtime.log
The text was updated successfully, but these errors were encountered: