Closed mindflayer closed 5 months ago
#5 43.30 File "/.venv/lib/python3.10/site-packages/pyproject_hooks/_in_process/_in_process.py", line 74, in _build_backend #5 43.30 ep = os.environ['PEP517_BUILD_BACKEND']
This is not the code in 1.1.0: https://github.com/pypa/pyproject-hooks/blob/v1.1.0/src/pyproject_hooks/_in_process/_in_process.py#L74
Please provide more complete details for reproducing this issue.
I am trying to understand what happened and why pinning the version made it pass.
Our poetry.lock
was pointing to pyproject-hooks==1.0.0
so it was downgraded during the packages installation. I am still trying to find the combination of tools that breaks the installation but it's definitely not an issue with the version released today.
I am still wondering why it happened today though...
Thanks for your support and sorry for the false alarm.
@mindflayer did you figure out? i'm having the same issue, also seems related to the pyproject-hooks
update
For me, I believe the root cause is that 1.0.0 was locked in the poetry.lock file, but then poetry itself pulled in 1.1.0 when it was pip installed. So there was a conflict. Either downgrading to 1.0.0 after pip installing, or upgrading to 1.1.0 in the lock file fixes things for me.
the environment variables passed from front-end to subprocess were changed at https://github.com/pypa/pyproject-hooks/pull/166
so my best guess as to how people are managing to hit this is:
poetry
, and pyproject-hooks
1.0.0 (or 1.1.0)poetry install
or whatever
poetry
should have been installed in its own isolated environment and not in the project they are managingpyproject-hooks
to 1.1.0 (or 1.0.0)pyproject-hooks
, but the pyproject-hooks
that is available in the environment is the other version@mindflayer did you figure out? i'm having the same issue, also seems related to the
pyproject-hooks
update
Sorry, I fixed pinning, as I mentioned yesterday, but I really had no time to spend in investigating the issue. Sorry.
As far as I understood so far, the problem is what @dimbleby explained. Thanks!
That sounds like a solid hypothesis. :+1: Unfortunately I don't see much that we can do about it from this side - we'll obviously try not to change the child process interface more often than necessary, but it's meant to be an internal detail.
On Poetry's side, perhaps it could detect if it's targeting the environment it is running in, and either a) refuse to modify it at all, b) special case pyproject-hooks and refuse to change that, or c) special case pyproject-hooks and forcibly reload it after installing a new version.
I expect poetry will just tell people to read the docs and install it properly, I doubt code is needed.
I expect poetry will just tell people to read the docs and install it properly, I doubt code is needed.
Well, this is the advanced installation they list under their doc:
python3 -m venv $VENV_PATH
$VENV_PATH/bin/pip install -U pip setuptools
$VENV_PATH/bin/pip install poetry
It's not clear enough IMHO.
Having gone through this process today, and having read the "big red box repeatedly", and noting that others are having this problem, perhaps a logical conclusion is that the poetry docs are not clear enough on the proper way to do installation, especially when docker is involved.
Hi there, I've just investigated a new failure appeared in my team's CI, discovering it's due to a new release which was just published (https://pypi.org/project/pyproject-hooks/1.1.0/).
Could you please have a look? We are using the latest versions of
poetry
andpoetry-core
, and pinning the previous version (1.0.0
) ofpyproject-hooks
fixed it.