pip-compile --upgrade and --upgrade-package needn't be mutually exclusive

[adamchainz]

Related to #829. I test some Django packages, with one requirements file for each. Sometimes I want to upgrade all the requirements in my files except Django, which I pin for each by passing e.g. --upgrade-package 'Django>=2.1,<2.2.

Currently the options are mutually exclusive but I think it makes sense to allow pip-compile --upgrade --upgrade-package 'Django>=2.1,<2.2 to mean "Upgrade all packages, except from add this constraint on Django.

Environment Versions

1. macOS
2. Python version: Pythons 3.5-3.7
3. pip version: 19.1.1
4. pip-tools version: 3.7.0

Steps to replicate

See description

Expected result

The pins combine

Actual result

Error "Only one of --upgrade or --upgrade-package can be provided as an argument"

[atugushev]

Looks like the --upgrade-package has been appeared in #409.

Hello, @nnja! Any chance to remember why --upgrade and --upgrade-package decided to be mutually exclusive?

[nnja]

Hi @atugushev -- That commit was quite a while ago!

My reasoning, in short:

• To me, update/upgrade means just that. Bump the version up, not lower it or keep it the same.
• This flag was introduced as a way to explicitly say "update only these specific packages"

I'm not an active user of this package any longer, but to me, this use case seems like a specific hack. Would it make more sense to be explicit and add a new flag, such as ignore or exclude that can be used with --upgrade and accepts a list of package names? It would mean "upgrade all packages except this one".

This approach would make the expected behavior clearer, instead of adding on to an existing feature.

[adamchainz]

The way I see it --upgrade-package is really just adding an extra constraint into the mix. --upgrade adds a "get the latest" constraint to a package, --upgrade-package foo adds a "get the latest foo" into the mix, and --upgrade-package foo<2 adds a "get the latest foo less than 2" constraint.

I don't see my use case as hack. I do still want to upgrade Django, just with an extra constraint. Since I'm compiling multiple requirements files, this saves me writing N requirements.in files that different just by their Django constraint. The ignore or exclude suggestions wouldn't help my use case, since they wouldn't let me upgrade all packages with an extra constraint on Django.

At this point, fixing #829 as per my PR #831 means we can remove the mutual incompatibility of --upgrade and --upgrade-package "for free" - it's only the validation step that needs removing. The rest of the compiling works fine with both of them there together, it seems like an easy win to me.