SemanticVersion support for serde not documented about pubgrub HOT 8 CLOSED

from pubgrub.

That is fascinating! I am very interested in hearing more or figuring out how I can help. Is there any chance of doing comparisons between the Python impl and our rust ones? Do we get the same answers? When is one faster or slower than the other? With that many packages in house, do you find cases where our current impl is slower then expected? ...

For your project what can be used as a version number? rez seams like it is setting up python environments. Python versions is PEP440 which is not semver. Someone was discussing a python version crate, now where was it... here!

from pubgrub.

Hi! Thank you for using our library!

Indeed, it looks like the only documentation of the "serde" feature is in the change log. It would make sense to document it better. PRs wellcome! In general we are not ready to guarantee the stability of our serde representations, but SemanticVersion seems pretty safe. For production users it probably makes sense to have your own type that implements Version and serializes the way you want, just to be sure we won't break you.

There are several reasons we have started with our own SemanticVersion instead of the Semver crate. Basically the Semver crate is on a very slow maintenance schedule. We need to move fast to experiment and figure out what APIs we will need before we try to get them added upstream. Also it is not yet clear if our traits are general enough to handle pre release version yet (cc pubgrub-rs/advanced_dependency_providers#3 and #49 and dtolnay/semver#223 ). I'd hate to get a release of the Semver crate only to discover we need some different functionality. It is definitely something we are working to support but it is not clear when it will happen.

from pubgrub.

In terms of comparing the Python implementation with the Rust one, that is my intention. I am quite curious to see how this stacks up. I will definitely provide feedback once I get to a good point.

Rez happens to be implemented in python, but the packages one builds with Rez are not traditional python packages. They are Rez packages which are concerned with configuring runtime environments in addition to build time environments. This is in contrast to most package management systems which are usually concerned with build/test time. A package may contain code written in a wide variety of languages - for us typically python and C++.

The Rez manifest (its version of a Cargo.toml file) is used to define various dependencies, as well as a set of commands to manipulate the environment - achieved through the manipulation of environment variables (like LD_LIBRARY_PATH, PYTHONPATH, etc). To fulfill the need to specify the runtime environment, users configure packages via a database backed gui which stores resolved dependency closures as well as the configuration (eg run package A with packages B, C, D, and E).

These user facing packages expose entry points (executables), and/or desired capabilities. Usually, these desired capabilities take the form of packages which extend the runtimes with plugins. The applications tend to be highly extensible, providing full featured apis, python runtimes, etc, and each pays attention to a wide variety of environment variables for extension/behavior modification.

Anyway, the addition of a solver allows the user to only concern him or herself with the desired capabilities for a runtime. Typically, a user may configure a runtime with a handful of of packages. However, these extension packages have a vast set of transitive dependencies which we solve for at configuration time.

Rez has a very inclusive mechanism for dealing with versioning which works for SemVer, but also provides greater flexibility for those that do not adhere to it.. I believe Rez basically splits version strings by period and performs comparisons according to internal heuristics, but also providing an affordance for custom version implementation on a per package basis.

That being said, Rez is an open source example that is similar to though not identical to our internal system. We have two Version implementations - one that adheres to SemVer, and another that allows a much more flexible approach, necessitated by vendors who do not adhere whatsoever to semantic versioning.

from pubgrub.

We need to move fast to experiment

That being said, if you like what you see currently @jlgerber you can use it already. I'm currently using version 0.2 of this crate "in production" for a tests runner for the elm language. If interested, you can see the dependency provider code here, and the code calling it here.

Currently the dev branch includes only performance optimization, no API changes (if I recall correctly). So most likely, we will release a 0.2.1 with no breaking change, even before a 0.3. And even when breaking API, it should be trying to make things more general and not more restricted, so very likely the upgrade path will be smooth.

All this to say, if you can use 0.2 today for your needs, don't hesitate because of potential future API changes. And if you can't because of some missing features, don't hesitate to have a look at some exploratory things happening in that repo: https://github.com/pubgrub-rs/advanced_dependency_providers/issues.

from pubgrub.

@jlgerber we are about to release version 0.2.1 of pubgrub and thus switching our attention on the limits of the current pubgrub API in order to support more advanced scenarios. So I have questions regarding the two versions schemes supported by your Rez alternative.

• Are the two versions implementations, the SemVer one and the other one, both usable together project-wise or even for the same package?
• For the SemVer one, do you support extensions like pre-release and build metadata?
• In the case you support SemVer extensions, what rules do you follow regarding the matching with range specifications. For example is 1.4-alpha.2 valid for > 1.3? and for < 1.4? and for >= 1.4-alpha.1?
• For the second flexible versioning scheme, is there still an order between versions? Do you use the same range specifiers or more restricted (like only == or such)?

from pubgrub.

I have a proof of concept implementation of support for the Semver crate, with one of the draft branches for 0.3.
The code is at: https://gist.github.com/Eh2406/88b8c799be3f3a6589073e8e58504a11
I think the concept can be extended to where a version needs different requirements depending on witch of a small number of categories it is in. (in my case pre-release or not).

from pubgrub.

Work on semver crate compatibly is now happening in https://github.com/pubgrub-rs/semver-pubgrub

from pubgrub.