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

Per-requirement --no-binary / --only-binary should not require name #4946

Closed
Kentzo opened this issue Dec 28, 2017 · 4 comments
Closed

Per-requirement --no-binary / --only-binary should not require name #4946

Kentzo opened this issue Dec 28, 2017 · 4 comments
Labels
auto-locked Outdated issues that have been locked by automation state: needs discussion This needs some more discussion type: enhancement Improvements to functionality

Comments

@Kentzo
Copy link

Kentzo commented Dec 28, 2017

  • Pip version: 9.0.1
  • Python version: 3.6.3

Description:

Currently both --no-binary and --only-binary require an argument even if they already belong to a requirement. Instead, they should not require any arguments. Specifying one should be an error.

Current:

pip==9.0.1 --only-binary pip

Should be:

pip==9.0.1 --only-binary
@pradyunsg pradyunsg added type: enhancement Improvements to functionality state: needs discussion This needs some more discussion labels Jan 19, 2018
@pradyunsg
Copy link
Member

Hi @Kentzo! Thanks for filing this issue!

This behaviour is useful when you specify more than one package as required for installation (say via a requirements file) where you only want to selectively specify these options for a certain package.

While it does get mildly repetitive in some cases, I don't really think that's are common/bad enough to warrant changing this behaviour introducing potential for ambiguity in interpretation of the command line and losing this fine control that the current form provides.

@Kentzo
Copy link
Author

Kentzo commented Jan 19, 2018

Current syntax should be retained. For requirements files it could be extended to deduce package name. Less space for an error.

@chrahunt
Copy link
Member

chrahunt commented Nov 9, 2019

Hello! Thanks for the suggestion.

I can see the appeal of implicitly applying options to the current requirement without requiring the option name. The downside of this approach would be the backwards incompatibility - we wouldn't be able to tell how to properly parse this for example: --no-binary --install-option 'example', because the --install-option is currently considered an argument to --no-binary. This coupled with the additional complexity added to the requirement file parsing logic (even after having been cleaned up pretty significantly) makes me lean pretty heavily in favor of keeping the current behavior.

Are there any other use cases we're missing that would justify the downsides?

@chrahunt chrahunt added the S: awaiting response Waiting for a response/more information label Nov 9, 2019
@no-response
Copy link

no-response bot commented Nov 24, 2019

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@no-response no-response bot closed this as completed Nov 24, 2019
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Dec 24, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Dec 24, 2019
@pradyunsg pradyunsg removed the S: awaiting response Waiting for a response/more information label Mar 17, 2023
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: enhancement Improvements to functionality
Projects
None yet
Development

No branches or pull requests

3 participants