I'm working on tools to convert python packaging data to rpm spec files. Most of the conversions are relatively straightforward, but there's an odd corner case with ">" and versions ending in ".*". That combination is parsed as a valid specification, but oddly, it seems to behave the same as ">= version", as demonstrated below. Is this intentional, or is it a byproduct of parsing ">1.0.*" as a LegacySpecifier? Should I convert ">1.0.*" into ">=1.0" and mimic the current behavior, or into something else, like "> 1.0", or ">= 1.1"?
pkg_resources._vendor.packaging.requirements.Requirement('cairocffi > 1.0.*,< 1.0.1').specifier._specs frozenset({<LegacySpecifier('>1.0.*')>, <Specifier('<1.0.1')>})
'1.7' in pkg_resources.Requirement.parse('foo>1.7.*') True
On Tue., 28 Jan. 2020, 3:52 pm Gordon Messmer, <gordon.messmer@gmail.com> wrote:
I'm working on tools to convert python packaging data to rpm spec files. Most of the conversions are relatively straightforward, but there's an odd corner case with ">" and versions ending in ".*". That combination is parsed as a valid specification, but oddly, it seems to behave the same as ">= version", as demonstrated below. Is this intentional, or is it a byproduct of parsing ">1.0.*" as a LegacySpecifier?
It's definitely not intentional, as PEP 440 only defines semantics for prefix matching in the context of "==" and "!=".
Should I convert ">1.0.*" into ">=1.0" and mimic the current behavior, or into something else, like "> 1.0", or ">= 1.1"?
Converting into "> 1.0" would make sense, as there's an implied "!= 1.0.*" in the use of the exclusive operator. I'd also recommend filing an issue with the projects publishing the ambiguous requirements. Cheers, Nick.
On 1/29/20 3:45 PM, Nick Coghlan wrote:
Should I convert ">1.0.*" into ">=1.0" and mimic the current behavior, or into something else, like "> 1.0", or ">= 1.1"?
Converting into "> 1.0" would make sense, as there's an implied "!= 1.0.*" in the use of the exclusive operator.
If "!= 1.0.*" is implied, wouldn't ">= 1.1" be the logical translation? If "> 1.0.*" is converted to "> 1.0", then 1.0.1 would be acceptable, correct? Of course, since there's no defined semantics for this, I could also simply refuse a conversion and bail out if we come across this corner case.
I'd also recommend filing an issue with the projects publishing the ambiguous requirements.
I haven't actually seen a project publishing this, I'm just trying to convert all of the conversion types that pkg_resources.Requirement will parse without throwing an exception, like it will for "~= 1.0.*" or "~= 1". (Unless your guidance is that I refuse undefined semantics). https://github.com/gordonmessmer/pyreq2rpm/ Thanks for getting back to me.
On Thu., 30 Jan. 2020, 10:02 am Gordon Messmer, <gordon.messmer@gmail.com> wrote:
On 1/29/20 3:45 PM, Nick Coghlan wrote:
Should I convert ">1.0.*" into ">=1.0" and mimic the current
behavior,
or into something else, like "> 1.0", or ">= 1.1"?
Converting into "> 1.0" would make sense, as there's an implied "!= 1.0.*" in the use of the exclusive operator.
If "!= 1.0.*" is implied, wouldn't ">= 1.1" be the logical translation? If "> 1.0.*" is converted to "> 1.0", then 1.0.1 would be acceptable, correct?
Yep, you're right. That means the translations would be: ">= 1.0.*": odd way of writing ">= 1.0" (since anything accepted by the prefix match would also be accepted as newer than 1.0) "> 1.0.*": odd way of writing ">= 1.1" (since anything older than 1.1 would be excluded by the prefix match) I haven't actually seen a project publishing this, I'm just trying to
convert all of the conversion types that pkg_resources.Requirement will parse without throwing an exception, like it will for "~= 1.0.*" or "~= 1". (Unless your guidance is that I refuse undefined semantics).
https://github.com/gordonmessmer/pyreq2rpm/
Thanks for getting back to me.
For this kind of automation project, accepting them, but converting them to more conventional spellings would make sense. It would likely be good if twine refused to upload them to PyPI, though (and/or PyPI refused to allow them to be uploaded). Cheers, Nick.
participants (2)
-
Gordon Messmer -
Nick Coghlan