Open gusutabopb opened 2 months ago
gusutabopb
commented
2 months ago For full disclosure, here's a MRE.
Note that pydantic is not available from http://registry.loc/simple
uv init
uv add pydantic --extra-index-url http://registry.loc/simplepyproject.toml
[project]
name = "uv-test"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.12"
dependencies = [
"pydantic>=2.9.0",
]uv.lock
charliermarsh
commented
2 months ago I would suggest inverting the order, such that your registry is the index-url and PyPI is the extra-index-url. In that case, we'll look at PyPI first, and only look at your registry for packages that don't exist on PyPI.
gusutabopb
commented
2 months ago Unfortunately, swapping out index-url and extra-index-url is not a feasible workaround in my case as the internal registry must have higher priority (checked first) as it contains a few packages that have name clashes with PyPI packages (completely different packages which happen to have a name that is already used in PyPI). Currently, the better workaround in my case is adding --disable-fallback to the instance of pypiserver running the internal registry.
However, my main points here are that the lock contents should:
extra-index-url was used or not when adding packages that do not depend on the extra-index-url at all (see the Pydantic example above).All points boil down to how HTTP redirects are handled when writing the lock file.
charliermarsh
commented
2 months ago Honestly I'm not sure that it'd be correct for us to write the redirected URL to the lockfile. We write the correct paths for the actual distribution files of course, but it's true that we found the package by querying the pypiserver URL. It would be strange if users saw registries in the lockfile that weren't included as index URLs at all in their configuration.
gusutabopb
commented
2 months ago Fair enough. I can see how that could be strange in case the redirected registry wasn't the same as index-url (which happens to be my case).
I guess it could be argued what I considered an uv issue was just a pypiserver misconfiguration.
Also, this should become less of an issue once https://github.com/astral-sh/uv/issues/171 is implemented.
Please feel free to close if the current behavior with regards to the different 303/404 handling is considered correct/expected.
Summary
I used
uv addwith anextra-index-urlto add a package that is not present in theextra-index-urlregistry.I expected uv to list the URL of the registry where the package actually lives as the "source". However, in case the registry returns HTTP 303 responses, uv lists the
extra-index-url(and not the default index = PyPI) as the "source".Is there some reasoning to listing the
extra-index-urlas "source" when it actually isn't?Details
I have an internal index/registry (e.g.
registry.loc/simple) at work (runningpypiserver), which contains just a few internal packages. It does not contain any packages that are available from PyPI. In order for those internal packages to beuv add-able, I haveextra-index-urlon myuv.tomlconfig.However, to my surprise
uv.locklists all the dependencies on my projects as coming from this internal registry. That is, thesourceregistry has the following for packages that were actually fetched from PyPI:Doing some digging, I found out that the registry returns an HTTP 303 response (which is the default behavior of
pypiserver), But uv doesn't list the redirected URL registry as the "source". My expectation is that for dependencies/sub-depdendencies fetched from PyPI after a redirect would list PyPI as the "source":Workarounds
extra-index-urlfromuv.tomland use it only when adding an internal package (e.g.my-lib)my-libwould still have the "wrong" source.--disable-fallbackflag topypiserverso an HTTP 404 response is returned instead.Environment