[rust-dev] Deprecating rustpkg

Tim Chevalier catamorphism at gmail.com
Thu Jan 30 14:28:13 PST 2014

On Thu, Jan 30, 2014 at 2:20 PM, Tony Arcieri <bascule at gmail.com> wrote:
> On Thu, Jan 30, 2014 at 11:26 AM, Tim Chevalier <catamorphism at gmail.com>
> wrote:
>> In the interest of documentation (especially for the benefit of
>> whatever person or people end up writing the next package manager),
>> can you explain what specific architectural issues in rustpkg preclude
>> the addition of (better?) dependency resolution and secure software
>> update infrastructure?
> rustpkg seems to have quite a few features (which it needs in its current
> state, I guess) I would prefer to see in a dependency resolution tool,
> including the ability to fetch from multiple different ad-hoc sources and
> integration with git repositories. These features do not seem to be
> particularly well thought out (e.g. how do we handle versioning?) and the
> "package identifier" system strikes me as rather odd.

Ah. These concepts are taken directly from the Go package manager:
http://golang.org/cmd/go/ . We believed at the time that this design
has worked well for the Go community, but perhaps someone who has used
Go can comment on that.

I'm not sure what your question is about versioning. Versioning in
rustpkg was not fully tested when I stopped working on it, but from
the start, the design was to treat different versions of the same
package as separate entities that can coexist. That's why package IDs
include optional versions.


> I would really like to see the "where packages come from" and "what packages
> are" concepts decoupled, as well as a clear strategy for how to handle
> versioning.

> --
> Tony Arcieri

Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt
"If you are silent about your pain, they'll kill you and say you enjoyed it."
-- Zora Neale Hurston

More information about the Rust-dev mailing list