Open con-f-use opened 5 years ago
I just posted PR #6447 for this.
This issue is a good starting point for anyone who wants to help out with pip's development -- it's simple and the process of fixing this should be a good introduction to pip's development workflow. See the PR above to understand what the desired fix could look like. :)
@pradyunsg Not to derail this particular issue, but I think this is not a good first issue; it might be a good second or third issue, but a contributor who is new to Python packaging is going to have trouble understanding specifiers, PEP 517, and so on. Removing the tag.
Sounds fair to me. We have an awaiting PR tag for things like this then -- stuff that's not a good first issue, but can be a good issue for more involved contributors to tackle. :)
Ideally we could move away from --no-use-pep517
, since it will be incompatible with an increasing number of packages as time goes on. What is the current use case for this flag?
I believe there are still packages out there using pyproject.toml
but not actually compatible with PEP 517. Instead of adding --no-use-pep517
we should probably hunt those packages down and fix them instead. Maybe it would help to add a message to --no-use-pep517
to prompt the user report the usage somewhere (e.g. in a tracking issue here)?
I removed the awaiting PR
label, following the two comments above.
I have a pyproject.toml
file in the root of the project with the following options.
[build-system] requires = ["setuptools", "wheel"]
I also have setup.py
file in the same directory.
Pip Version:
pip 21.3 from /opt/conda/lib/python3.8/site-packages/pip (python 3.8)
Command:
pip install -r requirements.txt
requirements.txt
--no-user-pep517 -e .
Error Message:
ERROR: Invalid requirement: --no-use-pep517 -e . pip: error: no such option: --no-use-pep517
I am curious though -- why do you want to pass --no-use-pep517
?
As it stands, this is effectively a request to expand on https://pip.pypa.io/en/stable/reference/requirements-file-format/#per-requirement-options. Coming into 2022, I don't think we want to make it easier to opt-out of the new build system logic -- the entire ecosystem is actively working to remove code paths that use the legacy logic of invoking setup.py
directly.
Yeah, It's an old bad addiction. I was looking at is there a more convenient option for that. I'm not requesting such a feature from the members. I'll also migrate the project to the new format.
I was looking at a solution to install the local package as editable with pyproject.toml
. It seems like migrating to the Setup.cfg
is much easier.
I reviewed PEP 518
, PEP 517
, PEP 621
, PEP 660
.
I'll try to use just only pyproject.toml
without setup.cfg
and setup.py
.
I was able to install my pyporject.toml
and setup.cfg
only project (no setup.py) editable with pip -e ...
, so I'd wager 660 is a go. Also, it is planned and there is a PR to read the core metadata from pyproject.toml
, which would be a big step to dtich setup.cfg
. That means 621 is not yet implemented but promising.
Environment
Description Specifying the option
--no-use-pep517
in a requirements file results inExpected behavior Package is installed not using PEP 517
How to Reproduce
pip install -r requirements.txt
(removing the option form the file and passing it directly works normal)Output
This Issue regards specifying
--no-use-pep517
inside a single requirement file. It is related to #6433, where it fails when we have nested requirement files and specify the option outside of them, i.e. give it directly as an argument to the pip invocation.