Support for various comparitors and range syntax

[jayvdb]

I noticed that this library has support for npm's range syntax.

Is the intention to support any sufficiently prominent syntax?

E.g. SpecItem("~>2.1.1") fails. This is Ruby's pessimistic operator, used in Gemfile extensively, and also used by D.

Another one is (,1.0] and similar used by Maven and Ivy (and most of the Java world), and also "Visual Studio" (and many many friends)

[jayvdb]

fwiw, I am interested in adding Ruby & D support if desirable. I am not in need of Maven/Ivy/etc support yet, but would like to know whether it (and others) would be permitted in the future.

There is also some rather complicated rules for rpm version syntax (c.f. https://github.com/sassoftware/python-rpm-vercmp) , and I suspect deb and other OS packaging software would need tweaks to work reasonably well.

[rbarrois]

Hello!

Thanks for the suggestion! I've followed up on this, and the library now support multiple range semantics, starting with NPM.

Would you be interested in grafting a RubySpec syntax parser?

[jayvdb]

You discarded #62 , and ignored #74 , which is now conflicted by your changes, and not reviewed. That strongly suggests that any future contributions here won't be valued, as you'll just ignore them and then commit your own equivalent enhancements which will of course will be better because you know your investment of time will be committed, whereas other people do not have that confidence.

fwiw, my own needs are now being met by https://github.com/dephell/dephell_specifier due to dephell/dephell_specifier#3 .

[rbarrois]

@jayvdb that is not my intention. I have left this library dormant for quite some time, because I needed to find a good pattern to allow for custom matchers.

And it happened that the internal design I had created initially was flawed; and had to be reworked significantly in order to address community suggestions.

I've tried to include a few pending feature requests in the updated version, hence closing #62, that was implemented in the new — and hopefully more robust — structure.

I will gladly accept contributions, and I'm sorry that your pull request arrived at a time I was already working on a separate branch on my device, making the patch moot.

Let me know if you still wish to bring this feature, that would be a good occasion for me to write docs about adding new range syntaxes :)