(Nit: dead code)

I worry about UV_INDEX_PROXY_URL not matching the UV_INDEX_<name>_USERNAME and UV_INDEX_<name>_PASSWORD options. Presumably, the reason the environment variables include the index name is it makes it easier to set variables for multiple indexes? We also may have just copied Poetry here. But, otherwise you have to pass them as separated values (with spaces here, commas in some other interfaces) — which is fine in the general case, but probably problematic for credentials where separators could be valid characters.

I'm not entirely sure this should change, but consistency is important. You could argue we should support UV_INDEX_USERNAME=<name>=<username> instead, but I don't know how we'd deal with the aforementioned case where the separator is a valid character in the value.

Another argument is that we don't have CLI options for usernames and passwords — they're part of the --index <...> value. It could be sufficiently distinct for that reason. We could weigh the usage of --index-proxy-url directly matching UV_INDEX_PROXY_URL over consistency with the other environment variables.

Another option is to support both, but I don't think there's strong justification for that.

Can index names contain a combination of dashes and underscores (e.g., alpha-1_b)? If there were a name like this, you couldn't specify it following the UV_INDEX_PROXY_URL_<name> approach.

My thinking was to keep the values of the command line arg and env var the same, but I'm open to alternatives.

We already support index names in environment variables, so there should be no "new" problems here.

The supported characters are at

and here's the environment variable key conversion

(I'm still undecided what's best for users here)

This is an edge case, but what happens if a user names one index alpha-b and another alpha_b? Do we treat those as the same name?

It's a good question — I think we should require unique normalized names and error if they do that. I'm not sure if we do today.

Agree that's the right behavior, which means it's not a reason against your env var proposal. Though I'm still not sure whether it's better to have the values be the same as for the cli arg.

On that note, can you check if we error and if not open a ticket to do so?

I'm leaning towards the <name> in the variable. I think consistency across our environment variables probably makes more sense than consistency between the CLI and environment; so:

UV_INDEX_<name>_USERNAME
UV_INDEX_<name>_PASSWORD
UV_INDEX_<name>_PROXY_URL

Will do. And yeah, I agree with you. Let's change it to your proposal.

Might be preferable not to use our proxy here, it's a bit flaky and I'd only use it if you're trying to test for proper credential management. You should just be able to use the normal PyPI?

Speaking of testing credentials, it may be worth having a separate test that uses the UV_INDEX... variables to set credentials and ensure they're propagated to the proxy URL correctly.

This is an interesting question. The proxy replacement only works if the url bases for sdists/wheels are the same as the canonical url. As @charliermarsh mentioned in the original issue, this isn't true for PyPi, which uses urls like https://files.pythonhosted.org/packages/94/49/26a7b0f3f35da4b5a65f081943b7bcd22d7002f5f0fb8098ec1ff21cb6ef/black-25.1.0.tar.gz.

Testing locally, I've been using devpi, which on its own writes your localhost URL as the base for everything. The PyPi proxy I'm using in this test has the same problem as PyPi. Do we have anything like devpi we've used for other tests?

Oh, interesting. That's.. tricky. I worry this will be a problem for users, but we can discuss that separately — be sure to call this out in the pull request summary and documentation.

We don't have anything like that for other tests. You can use the un-authenticated proxy at https://pypi-proxy.fly.dev instead. See https://github.com/astral-sh/pypi-proxy

Does it makes sense to allow --proxy-url <url> without a name? Like we do for --index <url>?

If so, I think it'd override the "default" index URL?

That could make sense, but my concern is that since PyPi is the default out of the box, it will increase the chances of users hitting confusing behavior.

It seems indicative that we'll need to find a way to fix the confusing behavior or provide a dedicated error message — but we can consider that separately. It's fine to not support in the initial version, as long as we've considered how it would work if we supported it in the future.