With `--use-pep517`, file:/// and tar.gz sdists support `setup.cfg` only source trees, but implicit file paths do not

Description

Interestingly, while testing this I noticed that, assuming ./pkgdir contains setup.cfg but no setup.py:

pip install file://$PWD/pkgdir works, but pip install ./pkgdir complains that Neither 'setup.py' nor 'pyproject.toml' found..

The “fix” for that would be easy (in is_installable_dir()), but I’m not sure how far these ripples will go…

_Originally posted by @sbidoul in https://github.com/pypa/pip/issues/9945#issuecomment-835770102_

Expected behavior

$ echo '[metadata]\nname=foo' > setup.cfg && pip install --use-pep517 file:///$(pwd)
ERROR: Directory '.' is not installable. Neither 'setup.py' nor 'pyproject.toml' found.

pip version

pip 21.2.4 from /home/graingert/.virtualenvs/testing39/lib/python3.9/site-packages/pip (python 3.9)

Python version

Python 3.9.7

OS

Ubuntu 20.04.3 LTS

How to Reproduce

$ echo '[metadata]\nname=foo' > setup.cfg && pip install --use-pep517 file:///$(pwd)
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=b0ec4bd32d639456067a52c0297824efbc46d9a1f7b3894c63106ed25c9168fa
  Stored in directory: /tmp/pip-ephem-wheel-cache-qxna4rsa/wheels/4c/98/64/53a57a6326621aeffd6d95082ac196bdb3e2a8459e121fa09a
Successfully built foo
Installing collected packages: foo
  Attempting uninstall: foo
    Found existing installation: foo 0.0.0
    Uninstalling foo-0.0.0:
      Successfully uninstalled foo-0.0.0
Successfully installed foo-0.0.0

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

GitHub now allows real markdown footnotes.

Does it? [^1]

[^1]: Ooh, yes it does[^2]! [^2]: I’m quite attached to my autohotkey macro for “superscript 1”, but having proper support is good[^3] [^3]: Unfortunately, it looks like Discourse doesn’t support footnotes, so I may stick with doing them manually for consistency.

OK, enough silliness for today 🙂

[layday]

It’s not a matter of whether people rely on it, it’s a matter of backends having decent error handling. I consider “I did something wrong and the tool produced garbage rather than spotting it and telling me” a legitimate bug report (against setuptools in this case).

This is not generic to all backends having “decent error handling” - it’s specific to setuptools, because only setuptools is invoked implicitly. I think we’re struggling to stay on top of when or not to invoke the legacy setuptools backend. There’s at least six different variables to consider and all of their combinations: has setup.py, has pyproject.toml, has build-table, has requires, has build-backend, and --[no-]use-pep517. Something has to give - either we invoke setuptools implicitly in fewer situations, or if we can remove the first variable, by delegating the setup.py existence check to the setuptools legacy backend, then we should probably do that.