Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UV ignores PIP_INDEX_URL? #2183

Closed
david-waterworth opened this issue Mar 4, 2024 · 2 comments
Closed

UV ignores PIP_INDEX_URL? #2183

david-waterworth opened this issue Mar 4, 2024 · 2 comments
Labels
duplicate This issue or pull request already exists question Asking for clarification or support

Comments

@david-waterworth
Copy link

We use AWS code-artifact as a private PyPi repository. Different tools (poetry/pip etc) have different mechanisms for controlling where to install from, i.e. for pip you need to set

PIP_INDEX_URL="https://aws:${CODEARTIFACT_AUTH_TOKEN}@${domain}-${account}.d.codeartifact.${region}.amazonaws.com/pypi/${repository}/simple/"

I did a quick test of uv - I like what I see so far but first without --verbose it doesn't tell me the index url where packages are being installed from. I think this is useful in cases where users are using a private index.

Setting --verbose it seems that it's ignoring PIP_INDEX_URL, i.e. uv pip install torch --verbose

 uv_client::cached_client::get_serde 
         uv_client::cached_client::get_cacheable 
           uv_client::cached_client::read_and_parse_cache file=/home/dave/.cache/uv/wheels-v0/pypi/nvidia-cusparse-cu12/nvidia_cusparse_cu12-12.1.0.106-py3-none-manylinux1_x86_64.http
 uv_client::cached_client::from_path_sync path="/home/dave/.cache/uv/wheels-v0/pypi/nvidia-cusparse-cu12/nvidia_cusparse_cu12-12.1.0.106-py3-none-manylinux1_x86_64.http"
   uv_installer::downloader::get_wheel name=triton==2.2.0, size=Some(167900779), url="https://files.pythonhosted.org/packages/95/05/ed974ce87fe8c8843855daa2136b3409ee1c126707ab54a8b72815c08b49/triton-2.2.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl"
     uv_distribution::distribution_database::get_or_build_wheel dist=Built(Registry(RegistryBuiltDist { filename: WheelFilename { name: PackageName("triton"), version: "2.2.0", python_tag: ["cp310"], abi_tag: ["cp310"], platform_tag: ["manylinux_2_17_x86_64", "manylinux2014_x86_64"] }, file: File { dist_info_metadata: Some(Hashes(Hashes { md5: None, sha256: Some("2039905bfe08510b724a9b3d16ff8d087889914358fda23faf669cc51efaa4dd") })), filename: "triton-2.2.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl", hashes: Hashes { md5: None, sha256: Some("a2294514340cfe4e8f4f9e5c66c702744c4a117d25e618bd08469d0bfed1e2e5") }, requires_python: None, size: Some(167900779), upload_time_utc_ms: Some(1704856316576), url: AbsoluteUrl("https://files.pythonhosted.org/packages/95/05/ed974ce87fe8c8843855daa2136b3409ee1c126707ab54a8b72815c08b49/triton-2.2.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl"), yanked: Some(Bool(false)) }, index: Pypi(VerbatimUrl { url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("pypi.org")), port: None, path: "/simple", query: None, fragment: None }, given: None }) }))
       uv_client::cached_client::get_serde 
         uv_client::cached_client::get_cacheable 

It looks like its downloading from https://files.pythonhosted.org and not AWS. Is there an alternative mechanism for setting PIP_INDEX_URL globally?

Also in passing, the default timeout of 300s isn't long enough to install torch.

error: Failed to download distributions
  Caused by: Failed to fetch wheel: torch==2.2.1
  Caused by: Failed to extract source distribution
  Caused by: Failed to download distribution due to network timeout. Try increasing UV_HTTP_TIMEOUT (current value: 300s).
@zanieb
Copy link
Member

zanieb commented Mar 4, 2024

Hi! You can use UV_INDEX_URL instead.

@zanieb
Copy link
Member

zanieb commented Mar 4, 2024

This is a duplicate of #1535 — you can see more discussion there.

@zanieb zanieb closed this as not planned Won't fix, can't repro, duplicate, stale Mar 4, 2024
@zanieb zanieb added duplicate This issue or pull request already exists question Asking for clarification or support labels Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists question Asking for clarification or support
Projects
None yet
Development

No branches or pull requests

2 participants