Adopt "vers" version range spec - #12
Conversation
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Also apply minor formatting Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Use namespaces rather than import renaming Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Based on the same code I wrote for Package URL. Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
This tests if a version is valid and is best closest to the gentoo code Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Using the join/split idiom is more powerful than just replacing spaces. It can handle any whitespace. Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Major refactoring: - rename version_range.py to version_constraints.py - then rename version_specifier.py to version_range.py The model is now working this way: - VersionRange is a collection of VersionConstraint with a specific Version class implementation to compare versions. - There is one VersionRange for each version scheme - A VersionRange can be built from a "vers" string or from a native, scheme specific syntax. - A VersionConstraint contains a comparator (such as =) and a Version instance - There are many Version implementations as before - Not all schemes are implemented, and a scheme is commonly the same string as a Package URL type. Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
| - It can parse native version ranges notation into the common "vers" notation | ||
| and can return back native version ranges from a "vers". |
There was a problem hiding this comment.
Just to be clear.
"parse native version ranges notation into the common "vers" notation" means converting ">1.2.3" to "vers:pypi/>1.2.3"
"can return back native version ranges from a 'vers' " . What is this "native version ranges" ? Is it a string representation of the range or is it an object ?
There was a problem hiding this comment.
is it a string representation of the range or is it an object ?
This is a string, for instance the one seen in an npm package.json for dependencies or in a setup.py install_requires
| >>> assert v24 in VersionConstraint(comparator="<=", version=v24) | ||
| >>> assert v24 not in VersionConstraint(comparator="<", version=v24) | ||
| """ | ||
| if not version: |
There was a problem hiding this comment.
But for "*" comparator, version is supposed to be None. Hence it will always return false which is opposite of what we're expecting.
There was a problem hiding this comment.
The version argument here is the version that we want to check. This is not the same as the version attribute of the constraint. You would never pass a constraint as an argument. The if not version: is just a guard against calling the method using None and other falsish values... but to your point this can be confusing and would be caught by the type check done below... so I am removing this line.
| if not version: | ||
| return False | ||
|
|
||
| # TODO: consider if we should accept any type and return False? |
There was a problem hiding this comment.
This is debatable, and I have no clear answer.
There was a problem hiding this comment.
Raising a ValueError is best for now, removed comment in latest commit
| return constraints | ||
|
|
||
| @classmethod | ||
| def to_constraints_string(cls, constraints): |
There was a problem hiding this comment.
Are doctest possible for this ? Maybe add some examples.
There was a problem hiding this comment.
Agreed and fixed in latest commit
| Return a VersionRange built from an npm "node-semver" range ``string``. | ||
| """ | ||
| # FIXME: code is entirely duplicated with the GemVersionRange | ||
| from semantic_version import NpmSpec |
There was a problem hiding this comment.
Why are the imports lazy ?
There was a problem hiding this comment.
I moved these to top level.
| Return a VersionRange built from a Rubygem version range ``string``. | ||
| """ | ||
| # TODO: Gem version semantics are different from semver: | ||
| # there can be commonly more than 3 segments |
There was a problem hiding this comment.
This could be added in the README
- from_vers() -> from_string() suggested by @sbs2001 - from_native_range() -> from_native() - to_native_range() -> to_native() Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Based on multiple review feedback from @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
None in VersionConstraint will now raise a ValueError. Reported-by: @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Suggested by @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Suggested by: @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
VersionConstraint.to_constraints_string is not a trivial function, soe some example help a lot Suggested by: @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
|
@sbs2001 Thank you for your detailed review! |
This adds univer from the current branch that support "vers". See aboutcode-org/univers#12 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Create NginxVersionRange.from_native method Contributed-by: Hritik Vijay <hritikxx8@gmail.com> Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
Suugested by: @sbs2001 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
c6331a9 to
588ef39
Compare
|
Merging now! |
This adds univer from the current branch that support "vers". See aboutcode-org/univers#12 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
This adds univer from the current branch that support "vers". See aboutcode-org/univers#12 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
This adds univer from the current branch that support "vers". See aboutcode-org/univers#12 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
This adds univer from the current branch that support "vers". See aboutcode-org/univers#12 Signed-off-by: Philippe Ombredanne <pombredanne@nexb.com>
This PR add support for the new vers draft specification for version ranges
The primary usage is going to be used in VulnerableCode to support
aboutcode-org/vulnerablecode#525
This a major refactoring of the library