Giter Club home page Giter Club logo

pysemver's Introduction

pysemver - Semantic Versioning for Python

Build Status

Usage

Work in progress. See the source code's doc strings for detailed descriptions.

"""pysemver: Semantic Version comparing for Python.

Provides comparing of semantic versions by using SemVer objects using rich comperations plus the
possibility to match a selector string against versions. Interesting for version dependencies.
Versions look like: "1.7.12+b.133"
Selectors look like: ">1.7.0 || 1.6.9+b.111 - 1.6.9+b.113"

Example usages:
    >>> SemVer(1, 2, 3, build=13)
    SemVer("1.2.3+13")
    >>> SemVer.valid("1.2.3.4")
    False
    >>> SemVer.clean("this is unimportant text 1.2.3-2 and will be stripped")
    "1.2.3-2"
    >>> SemVer("1.7.12+b.133").satisfies(">1.7.0 || 1.6.9+b.111 - 1.6.9+b.113")
    True
    >>> SemSel(">1.7.0 || 1.6.9+b.111 - 1.6.9+b.113").matches(SemVer("1.7.12+b.133"),
    ... SemVer("1.6.9+b.112"), SemVer("1.6.10"))
    [SemVer("1.7.12+b.133"), SemVer("1.6.9+b.112")]
    >>> min(_)
    SemVer("1.6.9+b.112")
    >>> _.patch
    9

Exported classes:
    * SemVer(collections.namedtuple())
        Parses semantic versions and defines methods for them. Supports rich comparisons.
    * SemSel(tuple)
        Parses semantic version selector strings and defines methods for them.
    * SelParseError(Exception)
        An error among others raised when parsing a semantic version selector failed.

Other classes:
    * SemComparator(object)
    * SemSelAndChunk(list)
    * SemSelOrChunk(list)

Functions/Variables/Constants:
    none
"""

License (MIT)

Copyright (c) 2013 Zachary King, FichteFoll

Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions: The
above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.

pysemver's People

Contributors

fichtefoll avatar wbond avatar

Stargazers

 avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

pysemver's Issues

Updates for semver 2.0.0

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.

Ranges with x-ranges are not supported

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'

Should `"<2.1.9"` satisfy `"2.1.9-pre"`?

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"]

SemSel.matches not the same as SemVer.satisfies

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.

Updating documention

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.