pip download --no-index not recording version with VCS url.

[saikonen]

Description

Using pip download with a VCS url for a Pep517 project and the --no-index --no-build-isolation flags results in the saved archive not having a correct version number appended.

Running the same command without the flags saves a correctly versioned archive.

Expected behavior

when using pip download with VCS urls, --no-index should not affect the name of the saved archive.

pip version

23.2.1

Python version

3.9.16

OS

macOS 13.5.2

How to Reproduce

1. pip download --no-index --no-build-isolation --dest . --no-deps git+https://github.com/pytest-dev/pytest.git
2. pip download --dest . --no-deps git+https://github.com/pytest-dev/pytest.git

Output

1. saves as pytest-0.0.0.zip
2. (at the moment) saves as pytest-8.0.0.dev275+g2401d766.zip

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

--no-build-isolation

When you do this, you're opting to create the build environment yourself and running pip in that context. IIUC, pytest gets the version via setuptools-scm which isn't installed in your environment and you're hitting pypa/setuptools#2329 (which takes lack of version to mean 0.0.0).

---

Closing this since this isn't really a pip issue, and is what pypa/setuptools#3511 is about.

[jaraco]

@pradyunsg Should pip and/or pyproject-hooks be silently launching the build backend without checking that the declared build-system.requires is satisfied? Maybe there should be at least a warning if --no-build-isolation is passed but the expected dependencies aren't present. That also might have helped avoid this issue. Imagine:

$ pip download --no-index --no-build-isolation --dest . --no-deps git+https://github.com/pytest-dev/pytest.git
...
WARNING: pytest requires `setuptools_scm>=N.N` but that package was not found. The build may not behave as expected.
...

That would also help other scenarios where the missing dependency will affect file discovery or other behaviors that also have fallback behaviors when the plugin is not present.

It doesn't seem feasible in general for the backend to detect that a declared dependency wasn't supplied, and while adding a requirement to fail if a version couldn't be detected would address this case, it wouldn't address the more general problem of detecting that a declared plugin's behavior wasn't provided.

I know historically, --no-build-isolation has been a "power user" feature and it's the responsibility of the caller to satisfy dependencies, but if that's the stance, I don't think we can rely on proxy failures deeper in the call stack to signal this faulty invocation.