Closed rt121212121 closed 1 year ago
I see this problem even with:
>>> from packaging.requirements import Requirement
>>> Requirement('requests=>2.8.*')
From what I can see, this is unexpected as per https://peps.python.org/pep-0508/#extras. This will be a problem with the packaging library, if it is indeed a problem.
UPDATE: I have found the underlying issue https://github.com/pypa/packaging/issues/645, which is causing this for my case (though not the case for the original question). In my case, it is by design (even if it is confusing/unexpected).
Hi @pelson, yes, I believe that is a separated problem and it is related to one of setuptools dependencies (packaging
).
Hi @rt121212121 ,
The requirement
python-pyscard>=1.6.12-4build1
has an invalid version (ref: PEP 440, PEP 508).
Yes, this is a regression (apparently in the packaging library). Either the breakage we are now seeing is ordained as the right path forward and packages that used to work, will no longer work and will have to be updated. A packages I do not maintain that I have been using for a decade is affected by this :-) Or we restore those packages to working and fix the regression.
Hi @rt121212121, I am afraid this is not a regression but an intentional change that has been planned in the ecosystem for a while. You can have a look on this comment for a reference:
From issue tracking management point of view, I believe that the best is to close this issue for now since this is a direct consequence of issue 3772
(also due to the fact that the changes would have to come from packaging
first).
At the end of the day, you have to do what is right for you.
But please keep in mind that as a Python developer I am continually finding things are breaking and then spending a day looking into it, then filing bugs and being told it is "by design". This happens for the Python 3.11 release where there are unadvertised breaking changes that look like bugs, and it happens for other things including Setuptools now.
These decisions cost me as a developer, they cost my employer, and they make it much much more unlikely to ever bother submitting bugs as the bugs are indistinguishable from features ... by design.
Thank you very much for the comprehension @rt121212121.
To help with this problem in the future (avoid loosing time with breaking changes) you can try running your test suite with all warnings turned into errors by default [^0] and selectively allowing minor warnings as needed[^1] (or at least with Python development mode activated). This should help you identify upcoming breakages and be prepared before they happen.
In setuptools we have been trying to communicate changes before hand and minimize the cost for the users as much as we can (and as much as it is viable for the project), using warnings and the changelog. Sometimes we will fail and I apologize for that, but Setuptools is an old code base and we have limited amount of time to work on it.
[^1]: It is unfortunate that Python silence deprecation errors by default. [^0]: You can use Python's -W option or pytest config for that.
For those who just need to get their project working pip install setuptools==57.1.0
then retrying my orignial command (pip install stable-baselines3
) then worked for me.
@rt121212121 if you hit this in your own library and you're defining extras_require
in a setup.py
, try adding the following to your pyproject.toml
:
[project.optional-dependencies]
Looks like by default, trying to get this field when it is missing results in a return type of []
, whereas when you have it present (even if empty) its results in {}
.
(@abravalheri so there might actually be a bug here, the default value of trying to fetch project.optional-dependencies
when it is missing from pyproject.toml
should be a dict not a list, e.g. https://github.com/pypa/setuptools/blob/2c28939e49c07b43b61642a9c5edb8a46afc9e00/setuptools/config/_apply_pyprojecttoml.py#L412)
setuptools version
setuptools==67.0.0
Python version
Python 3.10
OS
Linux / Ubuntu
Additional environment information
No response
Description
With latest setuptools I am unable to use a package (btchip-python) as input to pip-compile requirements for hash generation. It errors with:
If I downgrade setuptools to a version I know works, 65.5.0, the package works again.
The problem part of the project's setup.py file is:
It is triggered in the following command pip-compile does:
Expected behavior
Unless there is an obvious reason that setuptools is rejecting values it accepted before, I expect it to continue to accept them and no do breaking changes.
How to Reproduce
The simplest reproduction case is taking the erroring command from pip-compile and running it in a local copy of the package.
extras_require
complaint.Then with the older setuptools.
Output