cargo: add.

[elly]

This is a prototype of a package management tool for Rust. Run with no arguments
for usage information. Man page to be written.

Signed-off-by: Elly Jones [email protected]

[elly]

This is for <#866>, by the way.

[elly]

Yeah, I was thinking about that. This is a proof-of-concept, and it was quickest to write it in sh.

[brson]

Agreed that sh probably isn't a long-term solution here. marijnh, do you prefer that we translate it to python before merging it?

[marijnh]

Looks great! How do you intend to keep UUID list relevant? Wouldn't that have to include every version of every Rust module ever written to be useful? I think a by-name curated list, pointing at git/svn/hg repositories (tags for versions) OR multiple tarballs (one per version), would be more useful. If we support 'registering' multiple source lists (as in apt) that would be nicely decentralized, allow for a tool that indexes and searches packages, etc.

(Which is for the future. I have no objection to merging this patch.)

[graydon]

This is great. I'm glad to see such things develop. A few notes:

• I agree with marijn that if we're going to have a central (and hopefully, apt-like, extensible) registry-of-packages (say cargo.rust-lang.org as a default that we operate) we ought to permit grabbing them by short-name as well as UUID. That is, we should insist that anyone registering a package in a given cargo registry makes their package name unique to that registry, and the tool should probably default to just searching for a short-name, in the configured registries, if asked to fetch/install a schema-less pkgref (one lacking a ":" character)
• Rust can run subprocesses and (using librustc) parse its own crates. I was hoping to have this sort of tool not require too many additional tools; at risk of asking you to rewrite again, do you think this could be done in rust, and use crate-file attributes rather than separate manifests to dictate additional information? Just trying to err on the side of "fewest possible moving parts". Requiring python and shelling out to configure-and-make seems like more parts than I'd imagined.

In any case, promising start! I like the look of it.

[elly]

graydon: The short-name thing ought not to be a problem. As for parsing .rc files / rewriting in rust, I think that is a good idea; I didn't do it at first because I was unfamiliar with the librustc API. I believe that cargo as it is now (the python version) could be rewritten using only crate metadata.

The reason I wanted to add invocations of configure/make is to support packages that have native components. Does rustc know how to build native code if it's required by a crate file?

I will make an attempt at rewriting cargo in rust tonight.

[graydon]

I cherry-picked in the preliminary rust rewrite and added it to the build. Closing this; continue hacking in-tree and tracking in issue #866