(🎁) Fail and show an error when an invalid extra is requested

[KotlinIsland]

> uv --version
uv 0.1.29 (365cb16fd 2024-04-04)
> uv pip install basedmypy[among] basedpyright[us]
Resolved 6 packages in 571ms
Downloaded 1 package in 19.15s
Installed 2 packages in 57.88s
 + basedmypy==2.4.0
 + basedpyright==1.9.0

The imposter here should have been reported and caused the installation to fail

[charliermarsh]

We show these warnings on compile:

❯ echo "basedmypy[among]" | uv pip compile -
Resolved 4 packages in 5ms
warning: The package `basedmypy==2.4.0` does not have an extra named `among`.
# This file was autogenerated by uv via the following command:
#    uv pip compile -
basedmypy==2.4.0
basedtyping==0.1.3
    # via basedmypy
mypy-extensions==1.0.0
    # via basedmypy
typing-extensions==4.10.0
    # via
    #   basedmypy
    #   basedtyping

(I don't think we should fail, but we should warn.)

[DetachHead]

i think it should be an error for the same reason attempting to install a package that doesn't exist is an error. i spent hours the other day trying to figure out why an extra from a package i was using wasn't working, only to find out that it wasn't even installed because i specified the wrong name. warnings are very easy to miss

i can't think of a case where you'd ever want to specify an invalid extra, but if there is, i guess there could be an option to warn instead of fail. but i think it should fail by default

[charliermarsh]

I'm undecided but prior art from pip to understand why pip warns (but doesn't error):

• pip install should crash when an invalid extra/optional dependency is specified pypa/pip#12516
• Fail dependency resolution when a specified extra is invalid, instead of installing the base package without the invalid extra pypa/pip#9736
• pip silently fails to install extras and returns error code pypa/pip#7122

[samypr100]

For reference, pip itself just warns

pip install uvicorn[xyz]
WARNING: uvicorn 0.29.0 does not provide the extra 'xyz'

[charliermarsh]

I think part of the problem is that "whether an extra exists" can change over time, since extras can be added or removed. Should we backtrack to versions that do include an extra? If not, pip install uvicorn[xyz] would start failing at some point if the extra were removed.

[charliermarsh]

I added the warning for pip install in #2829 (but not going to close this issue until we decide whether to error).

[charliermarsh]

I think erroring is reasonable, we just need to consider the implications, because it would be a divergence from pip and so could break some workflows.

[samypr100]

Based on the threads you linked, it seems the only legitimate middle ground I see to avoid potential issue with transitives with invalid extras is pypa/pip#9736 (comment) where you'd enforce extras exists when supplied directly by the user, but don't enforce them when resolving them on transitives.

[KotlinIsland]

@charliermarsh Next can you do a reimplementation of python itself, all your projects make sound, well-thought out decisions that fix so many long standing issues with the ecosystem.

[jaraco]

To add some color to this discussion, I'm working on a build/test system that aims to move a lot of the project configuration into tooling and infrastructure. It assumes that every project under test is going to declare any test dependencies under the test extra and installs them when setting up to run tests.

Some projects, however, will have no project-specific test dependencies. In this case, the project gets built without any Provides-Extra: test in the metadata. I'm leaning toward having every project supply the test extra even when there are no dependencies, to suppress the warning under the current pip install technique but also satisfy a future where installers are more strict about installing them, such as this issue is proposing.

If you have any concerns about that approach, please comment in coherent-oss/coherent.test#5.

[karfau]

I have a setup where those extras are defined in setup.py but when running
uv pip install -e '.[test]'
it tells me

warning: The package `mypackage @ file://[...]` does not have an extra named `test`.

and also doesn't install any dependencies other then the package itself, not even the things in requirements.txt.

This is the case since v0.2.5, it works fine in 0.2.4.

Let me know if this is the right thread for this message or wether I should file a new issue.

[konstin]

@karfau That looks like a regression, please file a new issue with details how to reproduce your case!