On 13-06-27 02:39 PM, SiegeLord wrote:
I've been trying to understand how rustpkg is meant to be used, and I
found that it didn't quite mesh with my experience with other package
management systems. Since it's quite incomplete and under-documented,
instead of trying to comment on the status quo, I decided its best to
form a few scenarios of usage, and hopefully have the people who
understand where rustpkg is going help me to see if these scenarios are
going to be possible (or if not, what's wrong with them). To that end,
the syntax for rustpkg will be my own and not the current syntax.
Rustpkg does have some documentation. It's sparse and additions would
certainly be welcome. I suggest reading over the existing docs and
discussions:
https://github.com/mozilla/rust/blob/master/doc/rustpkg.md
https://github.com/mozilla/rust/wiki/Bikeshed-rustpkg
https://mail.mozilla.org/pipermail/rust-dev/2013-February/003200.html
I'll try to answer your preludes and scenarios based on what I know of
it, but please understand that there are a _lot_ of competing tensions
on rustpkg and not every user's intuitions are immediately met on first
encounter. Rather than redesign it (again) at this late a phase, I'd
like to see it completed and deployed, and adjusted as-needed based on
experience.
Prelude 1:
1 Package != 1 crate. I think a package should be able to contain
several crates. E.g. Debian packages routinely contain multiple
binaries/libraries etc.
This is true in the design we're currently working on.
Prelude 2:
Package source != package name. Regardless of where you get the package
from and no matter what the package file name was, the package metadata
(name/author/version) should not be affected, and should be the only
things that determine the identity of the package. I don't think these
things are inferrable, so I envision a metadata file with all those
things specified.
This is currently not true in the design we're working on. Or .. not
exactly. Packages are given a pkgid, which is a URL-fragment-like name.
It is _not_ a complete URL, but it's most of one, and it's standing in
for having separate metadata. It is enough that:
- It can be globally unambiguous by beginning with a DNS name
- It can be locally overridden by prepending some local prefix
- It may also be able to hint rustpkg at an internet access method
This does not mean that you must fetch a package named
"github.com/graydon/foo" from github.com, but it means that if you don't
have any other source for that package, you can guess at where to get
it. And it has a unique name (assuming you decide to use that fact).
This was chosen very carefully, very intentionally, and (for the time
being) we're not revisiting this choice. We experimented before with
having multiple points of name-indirection or metadata and it appears to
have just annoyed and confused everyone.
Scenario 1: Installation from a package file
I don't think this is on the current work list. It might be at some
point. It won't be especially hard, but neither is it hard to just
unpack a package in a workspace and build it using the existing
directory-based approach.
It is not installing to /usr/local or any filesystem global location by
default. It is intended to localize dependencies (in terms of using
nearby directories) as much as possible by default.
Scenario 2: Installation from an appropriately structured directory
In these cases, you pass a pkgid and it finds an installation candidate
using RUST_PATH. If it can't find a candidate it guesses an access
method for a remote from the pkgid and pulls that into the first entry
in RUST_PATH.
Scenario 3: Uninstallation
I don't think this is on the current work list but it's not hard.
Scenario 4: Fetching/building without installation
This is in the current work list. I do not think fetch is separate from
build, but it might be. Tim will know more.
Scenario 5: Specifying a workspace
Workspaces (each of which contains subdirectories for sources, builds
and installed binaries, per-package) are specified by RUST_PATH in the
current design.
-Graydon
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
