SemanticVersion support for serde not documented #78
Comments
jlgerber
changed the title
|
Hi! Thank you for using our library! Indeed, it looks like the only documentation of the 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. |
|
Thanks for the quick reply,
I am definitely excited to find an implementation of pubgrub that isn't
tightly coupled to any particular package management system. I thought that
I would have to do my own port to rust if I wanted to make use of the
solver. For context, I work in the Visual Effects field, and have started
prototyping a package management system using this crate, similar to
https://github.com/nerdvegas/rez. We tend to need to define dependency
closures for both build and runtime for all of our software packages (We
have roughly ~14k packages in house) on a per film and role basis, so a
solid dependency solver is a must. We currently have a python
implementation of pubgrub, but i am really interested in porting the system
to rust for obvious reasons...
Jonathan
…On Tue, Feb 16, 2021 at 7:16 PM Jacob Finkelman ***@***.***> wrote:
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
<pubgrub-rs/advanced_dependency_providers#3>
and #49 <#49> and
dtolnay/semver#223 <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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#78 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKLSSYEZTD3B4NCB7FBWW3S7MYIFANCNFSM4XXQTHNQ>
.
|
|
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! |
|
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. |
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. |
|
@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.
|
|
I have a proof of concept implementation of support for the Semver crate, with one of the draft branches for 0.3. |
|
Work on |
It would be great to document the serde feature for SemanticVersion.
Also, is there a reason for defining SemanticVersion as opposed to using the existing Semver crate which provides a full Semver2.0 implementation (SemanticVersion does not)?
The text was updated successfully, but these errors were encountered: