uv hangs on install from JFrog Artifactory, but only when building source distributions

[skellys]

uv version 0.1.16 hangs indefinitely on certain installs for me when using --index-url to install from JFrog Artifactory. I am not able to get this to happen when installing from the usual Internet/pypi.org. Fortunately, I am able to reliably reproduce my issue with a particular mix of 3 old, simple packages together, or when they're a part of a larger requirements.txt:

Repro

to repro, run in the official python:3.11-slim docker image:

python3 -m venv testenv
. testenv/bin/activate

# install uv from Internet
pip install uv

# install these 3 packages from an Artifactory cache endpoint
uv pip install --index-url "https://$USERNAME:[email protected]/artifactory/api/pypi/pypi/simple" binpacking==1.5.2 expbackoff==0.1.1 frozendict==2.4.0 --no-deps --no-cache --verbose

the end of the verbose logs before it hangs:

...
<similar for expbackoff==0.1.1>
...
<similar for binpacking==1.5.2>
...
DEBUG uv_distribution::source::download_source_dist filename="frozendict-2.4.0.tar.gz", source_dist=frozendict==2.4.0
uv_distribution::source::build_source_dist
DEBUG uv_distribution::source Building: frozendict==2.4.0
uv_dispatch::setup_build package_id="frozendict==2.4.0", subdirectory=None

Workaround

Pretty simple - just do regular pip install for those upfront, then uv pip install for the rest!

Can anyone else using JFrog Artifactory reproduce this issue? I ran this on an EC2 instance in AWS region us-east-1.

[charliermarsh]

Thanks, I think I'll need to setup an Artifactory repo to reproduce.

[cmwetherell]

Tangential, is there a way to specify the index-url for a project? Without needing to specify it for each new package install.

[zanieb]

You can use an environment variable e.g. UV_INDEX_URL — we'll add support for reading a persistent configuration file in the future too.

[skellys]

@charliermarsh Following up - I think we can close this issue. I'm no longer able to repro this as of version 0.1.18. There was another (separate) issue where I got HTTP 401 (unauthorized) errors for versions 0.1.22, 0.1.23, but I didn't observe that behavior again as of 0.1.24. Everything seems to work as of the latest version (at time of writing: 0.1.35).

[charliermarsh]

Oh great! Thank you for following up.