[rust-dev] Deprecating rustpkg
val at markovic.io
Fri Jan 31 14:59:34 PST 2014
On Fri Jan 31 2014 at 2:29:16 PM, Jack Moffitt <jack at metajack.im> wrote:
> > I am still confused about:
> > 1) In what situations are you saying there would actually be a workable
> > multi-version solution that wouldn't exist in a system like Maven
> > 2) How these solutions are calculated
> Every symbol in a crate is hashed with its version. You can load two
> extern mod's of the same libriary with different versions with no
> problems. Even within the same crate. To the extent that the two
> different versions aren't creating a socket to talk to each other with
> different versions of a protocol, this works fine. As an example,
> think about a JSON library that has undergone significant API changes.
> Each version can still read and write JSON, but the API to use them
> might be quite different. There's no inherent conflict to using both
> As for how you would calculate this, it's easy. You just use exactly
> the versions that the extern mods ask for. If they ask for a version,
> you pick that one. If they don't, you pick the newest one. This breaks
> the same way as any other algorithm when the unconstrained
> dependencies can't be resolved.
This is exactly the system I was referring to. Rust makes it easy to have
multiple versions of a library linked into a single binary. If the
libraries you depend on all ask for the latest (or unspecified) version of
a library, you pull in the latest. If they ask for a specific version, you
link that in as well.
The package manager should make this more granular as well; instead of
offering "latest" and "exact version", you specify depending on libfoo with
"latest", "1.2.3", "1.2.x", "1.x" etc. If the constraint is "1.x", you pick
the latest version that's still 1.x.
And then you link in *all* the libs that are necessary to satisfy the
various constraints, you *don't* look for the One True Version that
satisfies all of your deps.
> This is substantially different than the Java (or Erlang) world where
> the function names are not versioned behind the scenes and would
> clobber each other.
> Hopefully I haven't misunderstood your question.
> Rust-dev mailing list
> Rust-dev at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rust-dev