Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
con-f-use opened this issue Apr 24, 2019 · 11 comments
Open

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

con-f-use opened this issue Apr 24, 2019 · 11 comments
Labels
C: PEP 517 impact Affected by PEP 517 processing C: requirement file Using `requirements.txt`

Comments

@con-f-use
Copy link

con-f-use commented Apr 24, 2019 •
edited
Loading

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
  1. 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.
@con-f-use con-f-use mentioned this issue Apr 24, 2019
Closed
@cjerdonek cjerdonek mentioned this issue Apr 26, 2019
Closed
@cjerdonek
Copy link
Member

I just posted PR #6447 for this.

@cjerdonek cjerdonek added C: PEP 517 impact Affected by PEP 517 processing C: requirement file Using `requirements.txt` labels Apr 26, 2019
@cjerdonek cjerdonek mentioned this issue Apr 26, 2019
Closed
@pradyunsg pradyunsg added the good first issue A good item for first time contributors to work on label Jan 7, 2020
@pradyunsg
Copy link
Member

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 brainwane removed the good first issue A good item for first time contributors to work on label Jan 27, 2020
@brainwane
Copy link
Contributor

@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
Copy link
Member

pradyunsg commented Jan 28, 2020 •
edited
Loading

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

@pradyunsg pradyunsg added the state: awaiting PR Feature discussed, PR is needed label Jan 28, 2020
@chrahunt
Copy link
Member

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
Copy link
Member

uranusjr commented Jan 29, 2020 •
edited
Loading

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 sbidoul removed the state: awaiting PR Feature discussed, PR is needed label May 29, 2020
@sbidoul
Copy link
Member

sbidoul commented May 29, 2020

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

whitequark added a commit to amaranth-lang/amaranth that referenced this issue Jul 1, 2020
@whitequark
Revert "Add PEP 518 pyproject.toml."
416b253 
This reverts commit 7fca037.

This broke editable installs and has to be reverted due to a number
of pip issues:
  * pypa/pip#6375
  * pypa/pip#6434
  * pypa/pip#6438

We can put this back once PEP 517/518 support editable installs.
Until then the legacy behavior will suffice, and we should just teach
people to install the dependencies in virtualenvs or something...
bonzini pushed a commit to qemu/qemu that referenced this issue May 30, 2021
@jnsnow
python: add qemu package installer
36feb2d 
Add setup.cfg and setup.py, necessary for installing a package via
pip. Add a ReST document (PACKAGE.rst) explaining the basics of what
this package is for and who to contact for more information. This
document will be used as the landing page for the package on PyPI.

List the subpackages we intend to package by name instead of using
find_namespace because find_namespace will naively also packages tests,
things it finds in the dist/ folder, etc. I could not figure out how to
modify this behavior; adding allow/deny lists to setuptools kept
changing the packaged hierarchy. This works, roll with it.

I am not yet using a pyproject.toml style package manifest, because
"editable" installs are not defined (yet?) by PEP-517/518.

I consider editable installs crucial for development, though they have
(apparently) always been somewhat poorly defined.

Pip now (19.2 and later) now supports editable installs for projects
using pyproject.toml manifests, but might require the use of the
--no-use-pep517 flag, which somewhat defeats the point. Full support for
setup.py-less editable installs was not introduced until pip 21.1.1:
pypa/pip@7a95720

For now, while the dust settles, stick with the de-facto
setup.py/setup.cfg combination supported by setuptools. It will be worth
re-evaluating this point again in the future when our supported build
platforms all ship a fairly modern pip.

Additional reading on this matter:

pypa/packaging-problems#256
pypa/pip#6334
pypa/pip#6375
pypa/pip#6434
pypa/pip#6438

Signed-off-by: John Snow <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Reviewed-by: Cleber Rosa <[email protected]>
Message-id: [email protected]
Signed-off-by: John Snow <[email protected]>
bonzini pushed a commit to qemu/qemu that referenced this issue Jun 2, 2021
@jnsnow
python: add qemu package installer
ea1213b 
Add setup.cfg and setup.py, necessary for installing a package via
pip. Add a ReST document (PACKAGE.rst) explaining the basics of what
this package is for and who to contact for more information. This
document will be used as the landing page for the package on PyPI.

List the subpackages we intend to package by name instead of using
find_namespace because find_namespace will naively also packages tests,
things it finds in the dist/ folder, etc. I could not figure out how to
modify this behavior; adding allow/deny lists to setuptools kept
changing the packaged hierarchy. This works, roll with it.

I am not yet using a pyproject.toml style package manifest, because
"editable" installs are not defined (yet?) by PEP-517/518.

I consider editable installs crucial for development, though they have
(apparently) always been somewhat poorly defined.

Pip now (19.2 and later) now supports editable installs for projects
using pyproject.toml manifests, but might require the use of the
--no-use-pep517 flag, which somewhat defeats the point. Full support for
setup.py-less editable installs was not introduced until pip 21.1.1:
pypa/pip@7a95720

For now, while the dust settles, stick with the de-facto
setup.py/setup.cfg combination supported by setuptools. It will be worth
re-evaluating this point again in the future when our supported build
platforms all ship a fairly modern pip.

Additional reading on this matter:

pypa/packaging-problems#256
pypa/pip#6334
pypa/pip#6375
pypa/pip#6434
pypa/pip#6438

Signed-off-by: John Snow <[email protected]>
Reviewed-by: Vladimir Sementsov-Ogievskiy <[email protected]>
Reviewed-by: Cleber Rosa <[email protected]>
Message-id: [email protected]
Signed-off-by: John Snow <[email protected]>
@salihkaragoz
Copy link

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
Copy link
Member

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
Copy link

salihkaragoz commented Feb 15, 2022 •
edited
Loading

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
Copy link
Author

con-f-use commented Feb 15, 2022 •
edited
Loading

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: PEP 517 impact Affected by PEP 517 processing C: requirement file Using `requirements.txt`
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support --use-pep517 and --no-use-pep517 inside requirements files cjerdonek/pip
8 participants
@cjerdonek @uranusjr @sbidoul @brainwane @chrahunt @pradyunsg @con-f-use @salihkaragoz