pip-compile failure pep517/in_process/_in_process.py get_requires_for_build_wheel #1603
Comments
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
FWIW I can neither reproduce with the current versions of pip-tools and pip, nor those specified. I am testing with Python 3.9.7. Do you happen to be running on a non-x86_64 platform? |
|
I can reproduce it on x86_64 Windows and Ubuntu 20.04. Both platforms
started to fail at the same time.
Le ven. 25 mars 2022, 19:31, Andy Kluger ***@***.***> a
écrit :
… FWIW I can neither reproduce with the current versions of pip-tools and
pip, nor those specified. I am testing with Python 3.9.7.
Do you happen to be running on a non-x86_64 platform?
—
Reply to this email directly, view it on GitHub
<#1603 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA5EFSZMZU5TYCBONRYEEZ3VBYA67ANCNFSM5RTUYYUA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Does installing with pip alone succeed? |
|
We are having the same issue/error message in a project internal to my company, also working fine up until yesterday. @AndydeCleyre installing with pip alone succeeds in my case. |
This comment was marked as outdated.
This comment was marked as outdated.
|
A similar issue is affecting the pipenv builds and even though we no longer depend on pip-tools, it broke around the same time that the new setuptools package was released. I've got several hours in trying to actually pin setuptools or determine if that is really the cause or just a coincidence, but it broke for versions of pipenv that have been released since last November. We now only get one entry in the Pipfile.lock for this test case, whereas the expected result has several dependencies in it. Its kind of obscure, and I can share more details if it would be helpful. |
|
Can anyone experiencing this create a reproducible case in a container? Like $ podman run -it --rm docker://python:latest bash
# mkdir ~/proj
# cd ~/proj
# echo -e "from setuptools import setup\n\nsetup(name='apollo', install_requires=['conan==1.45.0'])" >setup.py
# pip install -U pip pip-tools setuptools
# pip-compile |
|
@AndydeCleyre Leaving docker out of the equation on my end. So far I in my debugging I am comparing the output of invoking the pipenv resolver in 2021.5.29 vs current versions (which worked up until a few days ago), and what I find is: When I run Now when I run: I get this much reduced output that is not correct, this is what the Pipfile.lock get based on: Now I downgrade to pipenv 2021.5.29 and re-run: So the issue I am experiencing seems to be specifically when the git repository is supplied (but not if it is manually cloned before hand), the pip resolver doesn't resolve all of the dependencies anymore. The weird thing is I have an old setuptools installed for my test and it doesn't matter, but I think maybe pip itself is pulling in the latest setuptools in the resolver ... I've tried pinning it in various places within pip internals to no avail, so maybe its something else entirely? |
|
So I will leave my feedback on what I found out with regards to It may be possible that any of my comments don't pertain to your issue and if so feel free to minimize any of them. I do find it interesting though the timing of setuptools release, and these two bug reports both concerning pep517 things for two projects that may do things in similar ways. Good luck! |
Yes |
I tried. Same behavior. |
|
@jeremy-coulon Not sure what version of virtualenv you have installed, but FWIW it brings in a specific version of setuptools and there was a new version of |
I am not sure which version of virtualenv I am using. It is coming from Ubuntu 20.04 packages. |
|
FYI I am creating my virtual env with: I am still confused of differences between |
|
Here is a reproducible Dockerfile: FROM ubuntu:20.04
RUN apt-get update && apt-get -y install python3-venv
RUN python3 -m venv myvenv
RUN myvenv/bin/pip install wheel "pip-tools<6.5" "pip>=21.2,<22"
RUN echo -e "from setuptools import setup\n\nsetup(name='apollo', install_requires=['conan==1.45.0'])" > setup.py
RUN myvenv/bin/pip-compile |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
@AndydeCleyre Can you try before the echo to print the version of setuptools in both cases? I wonder if they are the same or different between the passing and failing examples.
|
The interactive
Both report |
|
@AndydeCleyre 44.0.0 is pretty old and there is a new version of wheel recently, I wonder if they aren't compatible since you pip install wheel openly. Perhaps try upgrading setuptools in your test. |
|
@matteius I took the latest-posted RUN . ./myvenv/bin/activate && pip install -U wheel "pip-tools<6.5" "pip>=21.2,<22" setuptoolsThis installed setuptools |
|
This FROM ubuntu:20.04
RUN mkdir -p /proj
WORKDIR /proj
RUN printf '%s\n\n' 'from setuptools import setup' 'setup(name="apollo", install_requires=["conan==1.45.0"])' >setup.py
RUN apt -yqq update && apt -yqq install python3-venv
RUN python3 -m venv /proj/venv
RUN . /proj/venv/bin/activate && pip install -U wheel "pip-tools<6.5" "pip>=21.2,<22"
RUN . /proj/venv/bin/activate && pip list
RUN . /proj/venv/bin/activate && pip-compileThe only difference in the versions displayed by |
|
Hint: I've just had the same problem, and found this issue. For me the root cause was that my project was not installable at all (i.e. |
|
@fpatz What kind of change did you need to make? Minimized, outdatedOK here I'm going to try to investigate what the significant difference might be between this failing FROM ubuntu:20.04
RUN apt-get update && apt-get -y install python3-venv
RUN python3 -m venv myvenv
RUN . ./myvenv/bin/activate && pip install wheel "pip-tools<6.5" "pip>=21.2,<22"
RUN echo -e "from setuptools import setup\n\nsetup(name='apollo', install_requires=['conan==1.45.0'])" > setup.py
RUN . ./myvenv/bin/activate && pip-compileAnd this succeeding FROM ubuntu:20.04
RUN mkdir -p /proj
WORKDIR /proj
RUN printf '%s\n\n' 'from setuptools import setup' 'setup(name="apollo", install_requires=["conan==1.45.0"])' >setup.py
RUN apt -yqq update && apt -yqq install python3-venv
RUN python3 -m venv /proj/venv
RUN . /proj/venv/bin/activate && pip install -U wheel "pip-tools<6.5" "pip>=21.2,<22"
RUN . /proj/venv/bin/activate && pip list
RUN . /proj/venv/bin/activate && pip-compileI'll do it by incrementally changing the failing Tested Dockerfile variants (folded)
|
|
So based on @fpatz's comment and my discovery about the unexpected literal @jeremy-coulon Can you provide a reproduction in a container with a definitely valid package/ If it seems valid on your end, in addition to pasting it here, maybe also attach, and include an md5sum? EDIT: I suspect it's also important to house the |
|
@AndydeCleyre what I wrote was unrelated to the reproducer here; I simply botched my own project’s setup.py and got the same traceback, which led me here. That situation deserves a nicer error message, I’d guess. I’ll see if I can prepare a PR for the case of a a bad setup. |
|
Currently on my local machine, in master, running Python package versions[
{
"name": "asttokens",
"version": "2.0.5"
},
{
"name": "attrs",
"version": "21.4.0"
},
{
"name": "backcall",
"version": "0.2.0"
},
{
"name": "cheap-repr",
"version": "0.5.1"
},
{
"name": "click",
"version": "8.1.0"
},
{
"name": "coverage",
"version": "6.3.2"
},
{
"name": "decorator",
"version": "5.1.1"
},
{
"name": "distlib",
"version": "0.3.4"
},
{
"name": "execnet",
"version": "1.9.0"
},
{
"name": "executing",
"version": "0.8.3"
},
{
"name": "filelock",
"version": "3.6.0"
},
{
"name": "iniconfig",
"version": "1.1.1"
},
{
"name": "ipython",
"version": "8.2.0"
},
{
"name": "jedi",
"version": "0.18.1"
},
{
"name": "matplotlib-inline",
"version": "0.1.3"
},
{
"name": "packaging",
"version": "21.3"
},
{
"name": "parso",
"version": "0.8.3"
},
{
"name": "pep517",
"version": "0.12.0"
},
{
"name": "pexpect",
"version": "4.8.0"
},
{
"name": "pickleshare",
"version": "0.7.5"
},
{
"name": "pip",
"version": "22.0.4"
},
{
"name": "pip-tools",
"version": "6.5.2.dev3+g43e532c",
"editable_project_location": "/home/andy/Code/pip-tools"
},
{
"name": "pkg_resources",
"version": "0.0.0"
},
{
"name": "platformdirs",
"version": "2.5.1"
},
{
"name": "pluggy",
"version": "1.0.0"
},
{
"name": "plumbum",
"version": "1.7.2"
},
{
"name": "prompt-toolkit",
"version": "3.0.28"
},
{
"name": "ptyprocess",
"version": "0.7.0"
},
{
"name": "pure-eval",
"version": "0.2.2"
},
{
"name": "py",
"version": "1.11.0"
},
{
"name": "Pygments",
"version": "2.11.2"
},
{
"name": "pyparsing",
"version": "3.0.7"
},
{
"name": "pytest",
"version": "7.1.1"
},
{
"name": "pytest-cov",
"version": "3.0.0"
},
{
"name": "pytest-forked",
"version": "1.4.0"
},
{
"name": "pytest-rerunfailures",
"version": "10.2"
},
{
"name": "pytest-xdist",
"version": "2.5.0"
},
{
"name": "setuptools",
"version": "44.1.1"
},
{
"name": "six",
"version": "1.16.0"
},
{
"name": "snoop",
"version": "0.4.1"
},
{
"name": "stack-data",
"version": "0.2.0"
},
{
"name": "toml",
"version": "0.10.2"
},
{
"name": "tomli",
"version": "2.0.1"
},
{
"name": "tox",
"version": "3.24.5"
},
{
"name": "traitlets",
"version": "5.1.1"
},
{
"name": "virtualenv",
"version": "20.14.0"
},
{
"name": "wcwidth",
"version": "0.2.5"
},
{
"name": "wheel",
"version": "0.37.1"
}
]
and also tested with setuptools |
|
Ah, our scheduled CI jobs began sharing these failures 5 days ago. EDIT: I'm catching up with discussion from pypa/pyproject-hooks#116 (comment) |
|
Hi guys, I will try to have a look this evening on the failing jobs, but it would be really helpful from the setuptools point of view if you have an isolated reproducer. In terms of potential points of failure, v61 introduced a breaking change for "empty packages". They are now required to explicitly set The first reproduction with Dockerfile that fail in this thread did not met this new requirement. The following revision of the Dockerfile creates a brand new empty project root and simply adds setup.py to it and therefore succeds. Footnotes
|
|
Adding Thanks @abravalheri I must say that it is sad that we are forced to this new version of setuptools without any way to pin it to an old version. |
|
Hi all, I did some initial investigation on the failing tests and described my preliminary conclusions here. Hi @jeremy-coulon, sorry to hear that. I don't know exactly how is your setup, but the existing mechanism for projects pinning setuptools as a build-dependency is via [build-system]
requires = ["setuptools<61"]
build-backend = "setuptools.build_meta" |
|
I didn't have any Adding this file also solves my problem. Thanks. |
|
Thank you! Your help and explanation is very much appreciated. If there are no objections, I'll close this one soon. |
|
I encountered the same error message and stack-trace as @jeremy-coulon . In setup.py I had a non-PyPI dependency: setuptools will not accept that. does work. This is unfortunate, because This makes my setup.py brittle. |
My pip-compile was working fine yesterday and is now failing.
I don't know what changed. I know that my requirements.txt did not change and my pip-tools version did not change either.
I have seen issues #1535 and #1390 but no workaround works for me.
Environment Versions
LinuxPython 3.8.10pip 21.3.1pip-compile, version 6.4.0Steps to replicate
Expected result
success
Actual result
The text was updated successfully, but these errors were encountered: