Closed erickt closed 12 years ago
To get started, we could start with a simple shell script that runs with $script install graydon/re2
. This script would just connect to github and download a special tagged tarball. Inside, there would be a metadata file that states:
Which the driver would use to tell rustc which file to compile, and where to install. Figuring out a central repository could come later.
Bikeshed: What should the package manager and packages be named?
A while back we were discussing names, and we seemed to like "junk," but I don't know how serious we were about that. Telling people to write junk install re2
would be fun though.
In terms of metadata, I mentioned today on IRC that I think using the crate file itself should be an ok first go. Just parse the crate root and look for some "important" attributes in the root. We can say that you need a certain set of attributes to be undertood by the packaging tool.
Name-wise, I prefer things on the theme of intermodal container shipping, because I walk past such things every day and they are both very full of packages and crates, and often rusty. Ship, wharf, container, cargo, etc. would all be fine names imo.
erickt: I believe I have made a more-or-less faithful implementation of your idea, which I named 'cargo', per graydon's suggestion.
https://github.com/elly/rust-libs/blob/master/cargo
It supports installing packages (from source only for now) by:
The install-by-uuid thing is a gigantic hack - it works by fetching a file off one of my machines which is a list of uuid->install-methods. If people like this idea, I can write an appengine app to do this or something else.
By way of example and test, I have a package available at github:elly/rust-hello, http://www.leptoquark.net/~elly/rust-hello.tar, and uuid:83941200-18b3-41b1-8316-b98a2950b33a.
Anyone have thoughts on this? :)
Nice, elly. I think it is a promising start.
rustc and cargo need to agree on where rust software lives so that cargo-install libraries are automatically resolved by rustc. rustc can already give you the global sysroot with 'rustc --sysroot', but we should probably also have something like --hostlibs, because rust libraries currently live under /usr/lib/rustc/${arch}/lib. And then we also probably need rustc and cargo to share the same idea of where user-specific stuff lives.
I like just building packages straight from their git repo.
elly's cargo has some built in hash-based versioning that we probably want to merge with rustc's (mostly unimplemented) versioning.
As a result of further hacking, it now supports generation of manifests from crate files, and optionally signing (and verification) of packages.
...and as of https://github.com/elly/rust-libs/commit/bb062589031fc749289af4500d2256224b0b5a6e it can install rustc itself with this small patch to add a manifest: https://github.com/elly/rust/commit/ea56cabc11af9f15b73879caf85a9460485a957e
Try it: cargo install github:elly/rust@manifest
Having cargo, is this still an open issue?
I've been working on this. See src/cargo for current progress :).
I think it's fair to say we "have" a package management system now. Subsequent bugs are appropriate for feature work or such. I'll add a [cargo] tag.
Having a package management system like Perl CPAN, Ruby gems, and Python's PyPI would really simplify developing programs with rust. Ruby even has a couple other useful libraries built on top of gems, such as bundler, which lets you bake in the library dependencies into a project as well as install them into a local directory.
Open issues would be how to integrate sensibly with projects like Debian and Fedora that provide their own package management.