if the legacy install fails (eg if setuptools is not present) fall foward to use_pep517

[graingert]

What's the problem this feature will solve?

currently running pip install against a legacy project without a pyproject.toml while setuptools is unavailable fails:

echo 'from setuptools import setup; setup(name="foo")' > setup.py && pip install .
Processing /home/graingert/projects/foo
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
    ERROR: Command errored out with exit status 1:
     command: /home/graingert/.virtualenvs/testing39/bin/python3.9 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-oyuvbeju/setup.py'"'"'; __file__='"'"'/tmp/pip-req-build-oyuvbeju/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-pel3ovan
         cwd: /tmp/pip-req-build-oyuvbeju/
    Complete output (3 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    ModuleNotFoundError: No module named 'setuptools'
    ----------------------------------------
WARNING: Discarding file:///home/graingert/projects/foo. Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

forcing use-pep517 means the package installs fine:

echo 'from setuptools import setup; setup(name="foo")' > setup.py && pip install --use-pep517 .
Processing /home/graingert/projects/foo
  DEPRECATION: A future pip version will change local packages to be built in-place without first copying to a temporary directory. We recommend you use --use-feature=in-tree-build to test your packages with this new behavior before it becomes the default.
   pip 21.3 will remove support for this functionality. You can find discussion regarding this at https://github.com/pypa/pip/issues/7555.
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: foo
  Building wheel for foo (PEP 517) ... done
  Created wheel for foo: filename=foo-0.0.0-py3-none-any.whl size=933 sha256=2b1bd6b2bac2c68bc4aba9f72c1a24449ba1f33d066da9ab8d928f9fb10e5c81
  Stored in directory: /tmp/pip-ephem-wheel-cache-rz3q44s0/wheels/c1/61/2e/2e00770d914f4be99206a7f6965c1dc27263cd57a1eb7ad62f
Successfully built foo
Installing collected packages: foo
Successfully installed foo-0.0.0

this prevents ensurepip (and virtualenv) removing the setuptools bundled dep see here: https://mail.python.org/archives/list/[email protected]/thread/3BVAUIQOEOXAULHVYQNLLQIZQQETX2EV/#3BVAUIQOEOXAULHVYQNLLQIZQQETX2EV

Describe the solution you'd like

if the legacy install fails fall foward to use_pep517

Alternative Solutions

just remove the legacy install path eg #8102

Additional context

#10487

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

if the legacy install fails fall foward to use_pep517

I don't think we should be adding such try-a-different-build-system mechanisms.

We've started drawing clearer boundaries between the two build systems, with the intent of more clearly communicating to the users that the legacy mechanism is going to be removed (ALA #8102). Once the legacy build system is removed, we'll drop our runtime dependency on setuptools as well -- which seems to be the motivation here.

[pradyunsg]

All supported mechanisms to install pip will also install setuptools, so the only way you can do this is by getting things from a redistributor (in which case, go talk to them about why they changed things and how it creates a bad user experience for you) or by removing things that were there (you broke it, you get to keep both the pieces).

I think this, combined with the concerns I flagged above, serve as more than reason enough to not do this.

[encukou]

Just for the record: this report comes from a conversation about when one of the mechanisms – ensurepip – will drop setuptools.

[pradyunsg]

Yep yep, I'm aware. I've had enough bad experiences interacting with the old guard of CPython core developers in the recent past, that I won't bother responding over on python-dev.

That discussion also led to a PR that hasn't been mentioned on the thread FWIW, and that's where I've responded with my thoughts on what we should do here -- python/peps#2096 (comment).

[pfmoore]

I'm commenting over there (for the moment at least). IMO the only important point here is when ensurepip stops including setuptools. If we (the pip maintainers) are managing that, we'll do it at a point when it makes sense for us and our users (and if we disrupt any of our users, we'll take the flak as normal 😉). If python-dev¹ take over making that decision (for example, by insisting on following the IMO somewhat over-specific statement in the PEP) then 🤷 it's on them.

But honestly, I think this is all just talk. In reality we'll just continue as we have been and there's nothing to see here 🙂

¹ Disclaimer: I'm also one of the "old guard of CPython core developers". I'm wearing my packaging hat in this case, though - but I'd like to think I'm balancing the two roles without offending anyone 😉