Furthermore, it doesn’t use/manage PIP_EXTRA_INDEX_URL environment variable configuration as pip does too.

i am successfully downloading and installjng private packages using uv. Charlie’s tip on the updated gemfury address fixed it for me.

What is your full command (hiding any sensitive token), @iflare3g ?

With UV_EXTRA_INDEX_URL=https://**:****@****.pkgs.visualstudio.com/_packaging/***/pypi/simple/ges/pypi/simple/ set the command is just:

uv pip compile -o src/requirements/build.txt src/requirements/build.in --emit-index-url

without the env var, the command is:

uv pip compile -o src/requirements/build.txt src/requirements/build.in --emit-index-url --extra-index-url=https://**:****@****.pkgs.visualstudio.com/_packaging/***/pypi/simple/ges/pypi/simple/

and the result is for both:

 × No solution found when resolving dependencies:
  ╰─▶ Because xxx>=5.0 was not found in the package registry and you require xxx>=5.0, we can conclude that the requirements are unsatisfiable.

We use Microsoft’s DevOps Artifacts for mirroring PyPI

The only thing that knowingly doesn’t work is if you have a package that exists both in your private registry and on PyPI (i.e., packages with the same name), and you expect to use a version of that package from PyPI instead of your private registry. Is that the case here? Does xxx exist on your private registry?

yup, only into private registry it doesn’t exist at all on pypi , so no risk of naming conflicts

I’m waiting for this to be fixed as well. Else the resolution with index-url + extra-index-url is not working with uv compile vs pip-compile one.

@hofrob The answer is No. mylib is not using the same name as another library on PyPI.

Hello @zanieb

Thanks for your answer.

I’ve just tried adding UV_EXTRA_INDEX_URL. I’m using uv 0.1.5 and I have the following error still:

  × No solution found when resolving dependencies:
  ╰─▶ Because there is no version of mylib==2024.01.01 and you require mylib==2024.01.01, we can conclude that the requirements are
      unsatisfiable.

mylib==2024.01.01 is a lib in my private pypi repository. It seems it doesn’t use UV_EXTRA_INDEX_URL as well.

Can you try passing --emit-index-url on the command-line?

I think it would help if you shared the exact command you are running except for any secrets, and if you stick the verbose compilation log in a gist and share that too, I’m sure that would be helpful.

Edit: Sorry, I see you shared it above!

The only thing that knowingly doesn’t work is if you have a package that exists both in your private registry and on PyPI (i.e., packages with the same name), and you expect to use a version of that package from PyPI instead of your private registry. Is that the case here? Does xxx exist on your private registry?

yup, only into private registry it doesn’t exist at all on pypi , so no risk of naming conflicts

I’m waiting for this to be fixed as well. Else the resolution with index-url + extra-index-url is not working with uv compile vs pip-compile one.

me 2, it’s the only thing that blocks me and my team to fully switch to uv and we’d like to do as soon as this will be fixed and released

The only thing that knowingly doesn’t work is if you have a package that exists both in your private registry and on PyPI (i.e., packages with the same name), and you expect to use a version of that package from PyPI instead of your private registry. Is that the case here? Does xxx exist on your private registry?

yup, only into private registry it doesn’t exist at all on pypi , so no risk of naming conflicts

For clarity, this issue is now focused on whether we want to change our defaults around emitting index URLs.

@thomasaarholt - I filed your other issue here, thanks! https://github.com/astral-sh/uv/issues/2035

@thomasaarholt – Unrelated to this issue, but heads up: if you’re using Gemfury, you need to use pypi.fury.io instead of repo.fury.io in your index URL. Gemfury relies on the User Agent to do that mapping, and we (of course) don’t send pip in our User Agent:

@charliermarsh – mylib is not on PyPI. It’s a private lib/dependency only available from our private pypi repo. The resolution is working well with pip-compile from pip-tools with PIP_EXTRA_INDEX_URL environment variable setup.

You can use UV_EXTRA_INDEX_URL instead. We are hesitant to read pip’s configuration directly.

There are two more related issues here

unsupported environment variables

uv doesn’t support environment variables when the extra index url is supplied in requirements.in (it does work when passed via the --extra-index-url cli argument). With the following requirements.in file:

# requirements.in
--extra-index-url https://${GEMFURY_READ_TOKEN}@repo.fury.io/oda/

numpy

uv pip compile \
    --emit-index-url \
    requirements.in

generates

# This file was autogenerated by uv v0.1.3 via the following command:
#    uv pip compile --emit-index-url requirements.in
--index-url https://pypi.org/simple
--extra-index-url https://$%7BGEMFURY_READ_TOKEN%7D@repo.fury.io/oda/

numpy==1.26.4

uv doesn’t find private packages?

uv doesn’t find our company package called testy-foobar, while pip-compile does. With the following requirements.in file:

# requirements.in

testy-foobar

uv

uv pip compile \
    --extra-index-url=https://${GEMFURY_READ_TOKEN}@repo.fury.io/oda/ \
    --emit-index-url \
    requirements.in

generates

  × No solution found when resolving dependencies:
  ╰─▶ Because testy-foobar was not found in the package registry and you require testy-foobar, we can conclude that the requirements are unsatisfiable.

pip-compile

pip-compile \
    --extra-index-url=https://${GEMFURY_READ_TOKEN}@repo.fury.io/oda/ \
    requirements.in

generates

#
# This file is autogenerated by pip-compile with Python 3.11
# by the following command:
#
#    pip-compile --extra-index-url='https://****@repo.fury.io/oda/' requirements.in
#
--extra-index-url https://<STRIPPED>@repo.fury.io/oda/

asn1crypto==1.5.1
    # via snowflake-connector-python
cachetools==5.3.2
    # via google-auth
# many more packages

Yes, that works. It will add the default index-url too which makes sense. Thanks!

I guess this could be the default behavior?