You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
python-semanticversion currently appears to support "canonical" NPM version specs, as according to their range.bnf, but the node-semver implementation also accepts a superset of that syntax as valid.
For example, the implementation allows spaces between the prefix and the version (> 1.2.3), or additional whitespace within a hyphen-range (0.1.2 - 3.4.5).
It also has a ~> prefix, which appears to be equivalent to ~.
The NpmSpec does not accept these as valid, and raises a ValueError.
I believe that NpmSpec should aim to be equivalent to the node-semver implementation, correctly parsing anything NPM accepts as valid.
Note also the related issue npm/node-semver#392, which goes into more detail about the discrepancy between the syntax definition and the implementation.
The text was updated successfully, but these errors were encountered:
@pombredanne This approach would resolve the downstream bug I encountered (where the project accepts "npm style" versions, and the python implementation will sometimes reject version strings that are accepted elsewhere)
This would be similarly encountered by a python project that's needing to parse npm package.lock files.
But I appreciate trying to match some "reference implementation" is often much more troublesome than a well-defined spec, particularly if it's not communicated clearly whether those quirks are internal implementation details or not.
python-semanticversion
currently appears to support "canonical" NPM version specs, as according to their range.bnf, but thenode-semver
implementation also accepts a superset of that syntax as valid.For example, the implementation allows spaces between the prefix and the version (
> 1.2.3
), or additional whitespace within a hyphen-range (0.1.2 - 3.4.5
).It also has a
~>
prefix, which appears to be equivalent to~
.The
NpmSpec
does not accept these as valid, and raises aValueError
.I believe that
NpmSpec
should aim to be equivalent to thenode-semver
implementation, correctly parsing anything NPM accepts as valid.Note also the related issue npm/node-semver#392, which goes into more detail about the discrepancy between the syntax definition and the implementation.
The text was updated successfully, but these errors were encountered: