cargo: add. by elly · Pull Request #1149 · rust-lang/rust (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation7 Commits4 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
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 ellyjones@google.com
This is for <#866>, by the way.
Yeah, I was thinking about that. This is a proof-of-concept, and it was quickest to write it in sh.
Agreed that sh probably isn't a long-term solution here. marijnh, do you prefer that we translate it to python before merging it?
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.)
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.
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.
Elly Jones added 4 commits
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 ellyjones@google.com
Signed-off-by: Elly Jones ellyjones@google.com
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
bjorn3 added a commit to bjorn3/rust that referenced this pull request
Run the rustc test suite on CI
celinval pushed a commit to celinval/rust-dev that referenced this pull request
