relrod/pep440-rs

PEP440 version parsing library for Rust, WIP

pep440

This is a PEP440 version parser library for/in Rust.

Licensing

The test cases we use come mostly from the pypa/packaging source code, and to keep things simple, this library is licensed the same way that one is: Under the terms of either: Apache-2.0 or 2-clause BSD. See the respective license files for more information.

pep440-rs's Issues

Incorrect handling of .post0 modifiers in comparisons

Well, this is rather nitpicky :-)

According to PEP 440:

The post-release segment consists of the string .post, followed by a non-negative integer value. Post-releases are ordered by their numerical component, immediately following the corresponding release

"non-negative integer" means that .post0 is a valid post-release segment. And since it's a post-release segment, it should be ordered after the corresponding release. This also matches the behavior of packaging:

>>> from packaging.version import Version                                             
>>> Version("1.0") == Version("1.0.post0")                                            
False
>>> Version("1.0") < Version("1.0.post0")                                             
True

However, the code in this crate treats those two versions as identical for purposes of comparison: == returns True, < returns False.

I believe the bug is here:

pep440-rs/src/lib.rs

Line 443 in f031645

return me.post.unwrap_or(0).cmp(&other.post.unwrap_or(0))

post: None and post: Some(0) both get mapped to 0 for comparison purposes.

(Discovered this because I was messing with using https://crates.io/crates/pubgrub to resolve python package versions, and that algorithm wants to be able to represent version constraints as ranges. So == 1.0 compiles down to the range [1.0, 1.0post0).)

It seems it is currently unusable as a Python module

Tried the example from the ReadMe on PyPI:

from pep440_rs import Version, VersionSpecifier

got

cannot import name 'Version' from 'pep440_rs'

If it is not intended to be a python package, shouldn't pyproject.toml be removed to make that clear, and shouldn't it be written in the ReadMe that it has been published on PyPI by mistake?

Incorrect handling of trailing zeros in comparisons

Quoth PEP 440:

X.Y and X.Y.0 are not considered distinct release numbers, as the release segment comparison rules implicit expand the two component form to X.Y.0 when comparing it to any release segment that includes three components.

Unfortunately, this code acts differently:

use pep440::Version;

fn main() {
    let v1 = Version::parse("1.0").unwrap();
    let v2 = Version::parse("1.0.0").unwrap();

    println!("{}", v1 == v2);   // false  (should be true)
    println!("{}", v1 != v2);   // true   (should be false)
    println!("{}", v1 < v2);    // false  (correct)
    println!("{}", v1 <= v2);   // true   (correct)
    println!("{}", v1 > v2);    // false  (correct)
    println!("{}", v1 >= v2);   // true   (correct)
}

Note that this doesn't even define a consistent ordering -- the two versions are <= and >=, which should imply that they're ==... but they aren't.

I also noticed that normalize() doesn't convert these into the same form... which I think might actually be correct? I'm only like 90% sure. But it does mean that I can't use normalize() to implement a version of Hash that agrees with Eq, so now I'm not sure how to make versions hashable.