On Thu, Jan 30, 2014 at 2:20 PM, Tony Arcieri <[email protected]> wrote: > On Thu, Jan 30, 2014 at 11:26 AM, Tim Chevalier <[email protected]> > 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. Cheers, Tim > 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 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
