Passing a version range to -P results in no updates

[PeterJCLaw]

It seems that passing a package range to -P causes it pip-compile-multi to not upgrade the package in question at all, even when upgrades are available.

This is reproducible with:

# requirements/base.in
markupsafe

# requirements/base.txt
markupsafe==2.0.1
    # via -r requirements/base.in

$ pip-compile-multi  -P 'markupsafe<2.1.2'
Locking requirements/prod.in to requirements/prod.txt. References: []

Observing that while markupsafe has plenty of versions between 2.0.1 and 2.1.2, none are upgraded to.

Am I misunderstanding how -P is expected to work? I had thought I'd seen this work sometimes, but now can't actually reproduce that. -P seems to be documented to work the same as the equivalent pip-tools option, which does accept ranges and works with them.

[peterdemin]

Looks like there's a gap. Currently pip-compile-multi doesn't support the version, and always upgrades to the latest. You can only pass a package name. I didn't know pip-tools supports versions.
Would you be open to contributing a fix?

[PeterJCLaw]

Sure, I can have a go. From a quick look it seems like the missing piece is that UpgradeSelected compares the input text to the package names directly, though there may be more to it.

Do you have a suggestion for how the input string should be parsed to extract the package name? (I guess I'm asking if there's a known util somewhere that can do that, rather than me trying to write one)

[peterdemin]

Yeah, we need to use just the package name everywhere except when passing down the CLI options to pip-tools:
https://github.com/peterdemin/pip-compile-multi/blob/master/pipcompilemulti/features/upgrade.py#LL91C11-L91C11
To extract the package name, I guess, you could use a basic regex like this one:
https://github.com/peterdemin/pip-compile-multi/blob/master/pipcompilemulti/dependency.py#LL78C9-L78C37