Use python packaging.Version to handle versioning inside HaikuPorter instead of custom solution about haikuporter HOT 7 CLOSED

If I remember correctly, @kallisti5 already investigated this, and there are some differences in behavior. In particular, the handling of pre-releases is completely different: we use ~ instead of . as a separator to mark pre-releases.

So, in our case:

2.0 > 2.0~1
2.0 < 2.0.1

2.0 > 2.0.alpha
2.0 < 2.0~alpha

Maybe it is possible to achieve this with existing Python modules, but you have to be careful of handling all these situations, and the behavior must be similar to the C++ implementation in Haiku's package kit

from haikuporter.

Good point. Where can I find any documentation about versioning in Haiku? It would be very helpful to investigate if packaging.version can be used. I've found some hacks to use custom regex to parse the version but it looks like our own pattern should be created (original one is already strange and looks a bit odd).

from haikuporter.

Documentation is here: https://www.haiku-os.org/docs/develop/packages/BuildingPackages.html#version-strings but it is not complete, for example it does not specify how the strings in each component of the version are compared (it is some kind of "natural" order, so that numbers are sorted numerically and other strings are compared as strings)

from haikuporter.

Thanks for the link - I'll check if it's possible to adapt existing packaging and if it's worth the effort.

from haikuporter.

I've created PoC for adapting packaging.version to HaikuPorter (#261). I've checked the documentation and I think it should be easier to implement than I thought. If there are some differences between real world and the documentation for version strings please let me know - I will include such cases in unit tests for the new solution. Please let me know also what do you think about such change. I was planning to introduce it in two parts:

1. Implement new versioning mechanism.
2. Replace the old one with new one.

from haikuporter.

I don't know if we want to replace this class. Even if we can get 1:1 identical behavior with Haiku's specification, what's the point? We aren't packaging Python applications, so why would we use a class intended to deal with Python package version numbers? If the Python class's behavior changed in the future, we'd have to adapt things in HaikuPorter again, which just seems like needless work.

from haikuporter.

I agree with you. While I was digging deeper and looking at all of issues that pylint showed and many other things I came up with thought that this replacement is not needed at all. There are a lot more work to do now (UT for example or removing cyclic imports, etc.). I'm closing this discussion and PR.

from haikuporter.