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

Extra index url when it is specified over command line and uv.toml #3541

Closed
jmspereira opened this issue May 13, 2024 · 12 comments · Fixed by #3618
Closed

Extra index url when it is specified over command line and uv.toml #3541

jmspereira opened this issue May 13, 2024 · 12 comments · Fixed by #3618
Assignees
Labels
cli Related to the command line interface

Comments

@jmspereira
Copy link

Hey everyone,

I have a setup where I call uv pip install with an extra-index-url specified as a parameter, for instance:

uv pip install --extra-index-url

But during CI I want to overwrite the value of that flag, for that, I am using the uv. tom file where I have specified:

[pip]
extra-index-url = []

So the final setup is the uv.toml file and uv being called as mentioned previously (i.e., having 2 extra index URL).
However, it appears that uv is not looking the one specified in the configuration (contrary to what pip does). Is this supposed to happen? Or am I doing something wrong?

Best regards,

  • Jorge
@charliermarsh
Copy link
Member

Are you also providing the --extra-index-url on the command-line in CI? So in CI, do you have both the command-line argumnet and the uv.toml file present?

@charliermarsh charliermarsh added the question Asking for clarification or support label May 13, 2024
@jmspereira
Copy link
Author

jmspereira commented May 13, 2024

Correct, in CI I have both the command line argument and the uv.toml present

@charliermarsh
Copy link
Member

Ah, ok. Command-line arguments always take precedence over configuration files, so yes, this is the expected behavior. I think you'll need to find a way to avoid passing the command-line argument in CI.

@jmspereira
Copy link
Author

is there any reason to implement that behavior? That is not the behavior of pip when there are configurations specified as global in pip.conf

@charliermarsh
Copy link
Member

It's standard for the command line to override environment variables, and for environment variables to override configuration files. Even pip implements this (at least as-written here): https://pip.pypa.io/en/stable/topics/configuration/#precedence-override-order.

@jmspereira
Copy link
Author

Ok, I looked into it and the difference in behavior is that in the case of pip, for the concrete case of the extra-index-url (since it can take multiple values), the value passed in the command line is merged with the value specified in the config file (i.e., if you have 1 extra index url specified in pip.conf and another in the command line, in the end, the two are used).

@charliermarsh
Copy link
Member

Oh, you want both index URLs to be respected? I assumed from the original issue that you were trying to disable the index URL from the command-line given extra-index-url = [].

@jmspereira
Copy link
Author

Sorry If I was not explicit enough in the original issue, but yes, I would like to have both to be respected.

@charliermarsh
Copy link
Member

I think it's reasonable to merge here when the type is a vector? We at least merge when we discover multiple configuration files. What do you think @zanieb?

@zanieb
Copy link
Member

zanieb commented May 13, 2024

I think merging seems reasonable, we have --isolated to stop reading the configuration file.

@charliermarsh charliermarsh self-assigned this May 15, 2024
@charliermarsh charliermarsh added cli Related to the command line interface and removed question Asking for clarification or support labels May 15, 2024
charliermarsh added a commit that referenced this issue May 20, 2024
)

## Summary

If you have (e.g.) `extra-index-url` in your configuration file _and_
provide `--extra-index-url` on the command-line, we now merge the
options rather than ignoring those in the configuration file. As such,
merging the CLI and the persistent configuration is now semantically
identical to how we merge (project persistent configuration) with (user
persistent configuration).

Closes #3541.
@charliermarsh
Copy link
Member

Out now in v0.1.45. Let me know if you continue to see issues.

@jmspereira
Copy link
Author

Everything works as expected from my side, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli Related to the command line interface
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants