fichtefoll / pysemver Goto Github PK

http://semver.org was updated to 2.0.0 (stable) some time ago (no records for that) and introduced some changes. Since there weren't any "changes" pointed out I read through the whole thing and just noted everything that pysemver currently does not do in that way. Hopefully this is a complete list:

• MAJOR, MINOR and PATCH MUST NOT contain leading zeroes.

• Pre-release identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes.

  Note: Numeric identifiers with leading zeros are currently interpreted as ASCII identifiers.

• Build metadata identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes.

  Note: same as above

• Build metadata SHOULD be ignored when determining version precedence.

  Note: This was also included in 2.0.0-rc but I ignored it, I think I will make it the default and provide an option to disable that behavior.

The latter two kinda introduce issues for pysemver because I am violating them in order to implement sane selectors. Will have to brainstorm a bit in order to find the best solution. This is also highly related to #4.

I'll refer to sem vers with only the required parts (no pre-release or build) as "simple" and those with optional parts as "complex" from now on.

As of now,

>>> SemSel("<2.1.9").matches("2.1.9-pre")
['2.1.9-pre']

with a simple version selector and a complex version test this would match.
Is this expected behaviour? The same also applies for greater-than matches which would match any build variant of the simple version. To make the above example not match pre-releases the following selector can be used: "!2.1.9 <2.1.9".

I am thinking of defaulting every simple version selector with greater- or lower-than operators (>, >=, <, <=) to this "satisfying" behaviour. A | (or other) could be appended to the operator to make them explicitly "non-satisfying", like = can be used to make a plain version without a selector explicitly non-satisfying. Of course, complex version would always be "non-satisfying", as with simple non-satisfying 2.1.9-as selectors.

Thus:

>>> SemSel("<2.1.9").matches("2.1.8", "2.1.9-", "2.1.9", "2.1.9+", "2.1.10")
["2.1.8"]
>>> SemSel("<|2.1.9").matches("2.1.8", "2.1.9-", "2.1.9", "2.1.9+", "2.1.10")
["2.1.8", "2.1.9-"]
>>> SemSel("<=2.1.9").matches("2.1.8", "2.1.9-", "2.1.9", "2.1.9+", "2.1.10")
["2.1.8", "2.1.9-", "2.1.9", "2.1.9+"]
>>> SemSel("<=|2.1.9").matches("2.1.8", "2.1.9-", "2.1.9", "2.1.9+", "2.1.10")
["2.1.8", "2.1.9-", "2.1.9"]

The following should be translated to >=16.0.0- <19.0.0-.

>>> pysemver.SemSel('16 - 18')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/workspace/github/pysemver/semver.py", line 661, in __new__
    chunk = cls._parse(sel)
  File "/usr/local/workspace/github/pysemver/semver.py", line 791, in _parse
    raise SelParseError("Invalid ' - ' range '%s - %s'"
pysemver.semver.SelParseError: Invalid ' - ' range '16 - 18'

Just creating this issue for a reminder.

>>> SemSel('>1.0.0').matches('2.0.0')
['2.0.0']
>>> SemVer('2.0.0').satisfies('>1.0.0')
True

Either need to change the readme or change how this functions.

I updated the documentation on a branch. I would love to have your thoughts on the rewrite.