[rust-dev] Deprecating rustpkg

Tony Arcieri bascule at gmail.com
Fri Jan 31 15:32:26 PST 2014


On Fri, Jan 31, 2014 at 3:24 PM, Strahinja Markovic <val at markovic.io> wrote:

> I honestly can't even say I understand what exactly you mean by
> "toposort-style dependency resolution", but I can't help but feel that the
> answer to your question is *"Why do we care?".* Implementing an algorithm
> that fulfills the design I and others have proposed is trivial.
>

What is this algorithm, and what is a concrete example of a set of
dependencies that your hypothetical algorithm can solve which toposort
can't?


> What's the point? I don't know of any language other than Rust that
> doesn't bork when you link/load/eval multiple versions of a library in the
> same binary/process/interpreter. So no other language even *could *have
> implemented this without hacks like adding the library version to its
> name/namespace/whatever.
>
> Let's not limit what we can build for Rust by constraining ourselves to
> what others have built for languages that don't have Rust's capabilities.
>

If the dependency resolver can't support finding solutions which are
satisfied by multiple versions of the same library in cases where a
toposort-style dependency resolver can't, the entire endeavor is a
pointless waste of time which does nothing but complect the packaging
system and make it more confusing.

I am strongly suggesting before you go down this road you figure out:

1) *Exactly* what problem you're trying to solve
2) *Exactly* how you intend to solve it

RubyGems went down the road of trying to support the simultaneous
installation of multiple versions of the same package. However, Bundler,
the dependency resolution tool, ended up resolving packages to a single,
specific version. This made RubyGems support of multiple versions of
packages not only useless, but annoying, and even more cruft (e.g. rvm
gemsets) was added to work around the impedance mismatch between the
package manager and the dependency resolver.

I hope Rust will not make the same mistake for lack of better planning.

--
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140131/b0ce3275/attachment.html>


More information about the Rust-dev mailing list