You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The end-user section could be more clearly split between easy_install and pip sections, and make the mention that easy_install is used by setuptools < 52.0 in the main body of the text.
The end-user section talks about how to ensure easy_install invocations don't reach PyPI, but it doesn't give any comparable advice or commentary about more recent setuptools versions that use pip. It says in the historical context box that there's "limited ability to pass through any command line arguments", so does that mean you just can't stop it from hitting a different index to the user-initiated pip or is that passed through by default? At the very least, the behaviour should be clarified.
It doesn't cover that --use-pep517does make the current pip install the requirements, given they're passed back from setuptools per the normal build interface. This seems like it may actually be a better solution than "the best solution".
Shouldn't it be Setuptools' responsibility now to explain the easy_install configuration, not Pip's? (I think the current state of the documentation is the result of Pip and Setuptools' history of being intertwined.) If they already have something, perhaps that should just be linked from this part of the doc.
Description
Currently, pip has a bunch of docs about setuptools's old setup_requires: https://pip.pypa.io/en/stable/reference/build-system/#controlling-setup-requires
These have a number of problems:
easy_install
andpip
sections, and make the mention thateasy_install
is used bysetuptools < 52.0
in the main body of the text.easy_install
invocations don't reach PyPI, but it doesn't give any comparable advice or commentary about more recent setuptools versions that usepip
. It says in the historical context box that there's "limited ability to pass through any command line arguments", so does that mean you just can't stop it from hitting a different index to the user-initiatedpip
or is that passed through by default? At the very least, the behaviour should be clarified.--use-pep517
does make the current pip install the requirements, given they're passed back from setuptools per the normal build interface. This seems like it may actually be a better solution than "the best solution".Expected behavior
No response
pip version
N/A
Python version
N/A
OS
N/A
How to Reproduce
N/A
Output
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: