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

Add "block index" package index option #7723

Closed
mbardwell opened this issue Feb 12, 2020 · 8 comments
Closed

Add "block index" package index option #7723

mbardwell opened this issue Feb 12, 2020 · 8 comments
Labels
auto-locked Outdated issues that have been locked by automation state: needs discussion This needs some more discussion type: feature request Request for a new feature

Comments

@mbardwell
Copy link

What's the problem this feature will solve?

Often companies have privately hosted indexes that contain shared python libraries. If the index is set in the computers pip.conf, pip install checks that index. As it currently stands, the best way to test install behaviour with that index blocked is to remove the index from pip.conf

Describe the solution you'd like

It would be nice to have a command line method to block specific indexes

pip install mypackage --block-index-url http://pypi.company.com/simple

Alternative Solutions

--no-index would block the index but other indexes should still be available for testing

@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Feb 12, 2020
@chrahunt chrahunt added S: awaiting response Waiting for a response/more information state: needs discussion This needs some more discussion type: feature request Request for a new feature labels Feb 12, 2020
@triage-new-issues triage-new-issues bot removed the S: needs triage Issues/PRs that need to be triaged label Feb 12, 2020
@chrahunt
Copy link
Member

For the use case of testing install behavior I think it would make more sense to specify an explicit configuration file with PIP_CONFIG_FILE that has the index URLs you want (or not). In general we try to avoid adding additional configuration/arguments (see #6221), so an approach that avoids it is preferred.

@uranusjr
Copy link
Member

I wonder if it’d be possible to do something like

pip install --no-index -i https://pypi.org/simple --extra-index-url https://custom.index.example/simple

where --no-index resets the index list, and subsequent options add more just for this command.

@pradyunsg
Copy link
Member

@ei8fdb Another thing you might want to explore - how pip's index specification options work, and how we could possibly improve that.

@mbardwell
Copy link
Author

For the use case of testing install behavior I think it would make more sense to specify an explicit configuration file with PIP_CONFIG_FILE that has the index URLs you want (or not). In general we try to avoid adding additional configuration/arguments (see #6221), so an approach that avoids it is preferred.

If I understand correctly (big if), the user (person, CI, ...) could try install patterns by programmatically setting up an env and parsing the PIP_CONFIG_FILE to feed the -i or --extra-index-url args

On a computer with an index in pip.conf, any program like so (unless they altered the pip.conf file, yuck) would not fix the problem in this issue

@no-response no-response bot removed the S: awaiting response Waiting for a response/more information label Feb 13, 2020
@mbardwell
Copy link
Author

I wonder if it’d be possible to do something like

pip install --no-index -i https://pypi.org/simple --extra-index-url https://custom.index.example/simple

where --no-index resets the index list, and subsequent options add more just for this command.

I like this. Solves the #6221 concern.

Not sure how OS works. Do you typically wait for consensus from maintainers before going ahead with the implementation?

@chrahunt
Copy link
Member

I wonder if it’d be possible to do something like

pip install --no-index -i https://pypi.org/simple --extra-index-url https://custom.index.example/simple

where --no-index resets the index list, and subsequent options add more just for this command.

In this proposal, is it not resetting --index-url and --extra-index-url because they are after --no-index on the command line or because they are provided as command-line arguments and the other indexes that get overridden are in a config file which has lower precedence? Either way deviates from the way we currently handle other arguments.

For the use case of testing install behavior I think it would make more sense to specify an explicit configuration file with PIP_CONFIG_FILE that has the index URLs you want (or not). In general we try to avoid adding additional configuration/arguments (see #6221), so an approach that avoids it is preferred.

If I understand correctly (big if), the user (person, CI, ...) could try install patterns by programmatically setting up an env and parsing the PIP_CONFIG_FILE to feed the -i or --extra-index-url args

On a computer with an index in pip.conf, any program like so (unless they altered the pip.conf file, yuck) would not fix the problem in this issue

What I am saying is that if you want to test installation of your package and you do not want pip to use an index URL that may be configured in a system pip.conf, then create a config file with index-url set to whatever you want to test (or nothing) and then set PIP_CONFIG_FILE to the path to that file. Then pip will not read the system-level pip.conf.

@uranusjr
Copy link
Member

In this proposal, is it not resetting --index-url and --extra-index-url because they are after --no-index on the command line or because they are provided as command-line arguments and the other indexes that get overridden are in a config file which has lower precedence? Either way deviates from the way we currently handle other arguments.

I was thinking about the former; to generalise, the proposal is to make it possible to “reset” config file and environment variables in list form from the argument list. Indeed this deviates a lot from the current argument parsing mechanism (and thus not really viable without significant work). This would need to be a topic to evaluate in the UX research first, as mentioned above.

@chrahunt
Copy link
Member

chrahunt commented Mar 4, 2020

I think that my comment above helps provide a workable approach for testing. Taking into account that this is something users are not likely to run into, the general desire to limit the number of CLI options in pip, and that we now have an explicit issue (this one) that people can find if they are in a similar situation, I will close this. The more general proposal at #4263 may be good to look at for anyone interested in improving this area of pip.

Thank you @mbardwell for this proposal and for your prototype.

@chrahunt chrahunt closed this as completed Mar 4, 2020
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Apr 4, 2020
@lock lock bot locked as resolved and limited conversation to collaborators Apr 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation state: needs discussion This needs some more discussion type: feature request Request for a new feature
Projects
None yet
Development

No branches or pull requests

4 participants