Option --no-use-pep517 not supported in requirement files

[con-f-use]

Environment

• pip version: 19.1
• Python version: 3.6.7, 2.7.15
• OS: any

Description Specifying the option --no-use-pep517 in a requirements file results in

ERROR: Invalid requirement: --no-use-pep517 docopt pip: error: no such option: --no-use-pep517

Expected behavior Package is installed not using PEP 517

How to Reproduce

1. Have this requirements file:

   --no-use-pep517 docopt

2. Run pip install -r requirements.txt (removing the option form the file and passing it directly works normal)

Output

pip install -r requirements.txt 
Usage: pip [options]

ERROR: Invalid requirement: --no-use-pep517 docopt
pip: error: no such option: --no-use-pep517

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.

[cjerdonek]

I just posted PR #6447 for this.

[pradyunsg]

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. :)

[brainwane]

@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.

[pradyunsg]

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. :)

[chrahunt]

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?

[uranusjr]

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)?

[sbidoul]

I removed the awaiting PR label, following the two comments above.

[salihkaragoz]

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

[pradyunsg]

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.

[salihkaragoz]

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.

[con-f-use]

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.