Update pip compatibility guide to note transitive URL dependency support

[charliermarsh]

Summary

Closes #8080.

[slochower]

When reading the original text and this version, it sounds (to me) like you are suggesting a workaround of adding the URL dependency to your pyproject.toml or requirements.in (in the case that you depend on registry package A which depends on package B with a URL dependency). Rather, I think the advice is to add the URL dependency directly to package A in that scenario. Would phrasing like this be more clear?

If uv rejects a transitive URL dependency in a package from a registry, the best course of action is to provide the URL dependency as a direct dependency in the pyproject.toml or requirement.in file of the registry package, as the above constraints do not apply to direct dependencies.

Maybe it is a little clunky, but I definitely spent a few hours thinking I could just add the transitive URL dependency as a direct dependency in my package and that would satisfy uv.

[charliermarsh]

If you depend on a package A from the registry, which lists package B as a direct URL dependency (e.g., B @ https://...), adding package B to your pyproject.toml will work. That's the recommended solution. Something like:

[project]
dependencies = ["A", "B @ https://..."]

[slochower]

Ah, sorry -- I'm talking about one more layer of redirection. Say I'm writing a script with inline metadata. The script depends on registry package A. Registry package A depends on registry package B. In package B's pyproject.toml is a URL dependency. Adding that URL dependency directly to the inline metadata of a script will not satisfy uv run. I'm not sure there is a solution. Is there?

[charliermarsh]

I would actually still expect that to work. Are you running into a failure there? The way to think about it is: it's actually fine if registry packages depend on URL dependencies, but uv has to know about all possible URL dependencies upfront.

[slochower]

If I run without adding the URL dependency, I get:

error: Package `openeye-toolkits-python3-osx-universal` attempted to resolve via URL: https://pypi.anaconda.org/openeye/simple/openeye-toolkits-python3-osx-universal/2023.1.1/OpenEye-toolkits-python3-osx-universal-2023.1.1.tar.gz. URL dependencies must be expressed as direct requirements or constraints....

If I add openeye-toolkits-python3-osx-universal @ https://... to my script metadata, I then see:

error: No `project` table found in: `/Volumes/xxx/pyproject.toml

If I use uv run --no-project I still see the same thing, confusingly.

❯ uv run tmp.py --no-project

error: No `project` table found in: `/Volumes/xxx/pyproject.toml`
(.venv) 

The script metadata looks like this:

# /// script
# requires-python = ">=3.10"
# dependencies = [
#   "package-hosted-on-internal-registry==3.3.0",
#   "openeye-toolkits-python3-osx-universal @ https://pypi.anaconda.org/openeye/simple/openeye-toolkits-python3-osx-universal/2023.1.1/OpenEye-toolkits-python3-osx-universal-2023.1.1.tar.gz"
# ]
# ///

[charliermarsh]

I think you need to put the no-project flag before the filename, not after. Otherwise, it’s treated as an argument to the Python call.

[slochower]

Ah! Great, thanks.

This comment of yours really helped:

The way to think about it is: it's actually fine if registry packages depend on URL dependencies, but uv has to know about all possible URL dependencies upfront.

And maybe some form could be put into the documentation.