----- Original Message -----
> From: "Zack Corr" <zackcor...@gmail.com>
> To: rust-dev@mozilla.org
> Sent: Monday, June 4, 2012 4:31:11 AM
> Subject: [rust-dev] Cargo proposal - thinking about better ways to represent
> sources
>
>
> Hello everyone,
>
>
> I have committed myself to add dependency support for Cargo.
Yay!
> The way
> Cargo sources are currently implemented isn't right in my eyes and I
> have discussed this with Brian and he said we would re-discuss it
> tomorrow, but I live in a different time zone so I probably won't
> get hold of him. So I have written up a rough proposal here because
> I feel this should be proposed before I start trying to implement
> dependencies in the current system. It's a bigger document than it
> should be because I go on a bit.. but I'll summarise the general
> gist of it.
>
>
> > Currently, each source contains a packages.json file. Whenever a
> > new package is added, the user would need to cargo sync the
> > packages.json file. This would also need to be done, if
> > dependencies were implemented, whenever a package has a new
> > version. Coupled with the extremely bad usability of this
Why is this extremely bad for usability? Would it be bad if we
automatically synced the sources?
> > lots of packages, there could be quite large package.json files if
> > there are eventually thousands of packages. @brson suggested that
> > it could do a git pull so it only grabs changes, but this would
> > not apply for sources that don't run on git. The alternative is to
> > not have a central package and instead an API that sources follow
> > (not really an API, as it can be implemented with static files
> > just like the current system can be hosted on Github).
>
>
> I propose the following:
>
>
>
> <url>/source.json - access to a source's information (such as signing
> keys)
What other information? The packages.json file on cargo-central doesn't
appear to contain any information that belongs here.
> <url>/crates.json - access to a an array of all packages in the
> source (by name), used by the cargo list feature
> <url>/crates/<name>.json - access to a certain crate's information by
> name (equivalent to the objects inside packages.json
> OPTIONAL: <url>/crates/<uuid>.json - access to a certain crate's
> information by uuid (will probably change)
Can we put the uuid in crates.json so we don't have to list the crate's
information in two files? Presumably the uuid never changes.
> OPTIONAL: all of the above files have a .sig file each. Only require
> if the source.json file specifies a key.
Making Graydon sign so many files is asking a lot.
An entry in the current packages.json file looks like this:
{
"name": "rustray",
"uuid": "c89c5834-63db-4a6e-8e0a-d75985b1730e",
"url": "git://github.com/brson/rustray",
"tags": ["example", "graphics"],
"method": "git",
"description": "A raytracing proof-of-concept in Rust."
},
Under the proposed scheme I would imagine 'name', 'uuid' 'tags' and
'description'
still need to go into crates.json so that they can be discovered from the UI.
The other two are details that could be left to the package-specific file and
only retrieved during install. Is that right?
>
> This way it can still be used on Github, but can also be implemented
> dynamically, so it's pretty much an `API`. e.g. we could still use
> https://raw.github.com/mozilla/cargo-central/master as the source
> URL, and then have a source.json file, a crates.json file and then
> have crates/rustray.json files.
Do you have scenarios in mind where we might want to implement this API
instead of leaving it up to static file serving?
> tl;dr - I am proposing that Cargo does not have a single
> packages.json as this requires syncing every time there is a version
> or other info change for a single package. Instead, the information
> for a package is accessed when it is being installed. This document
> also discusses how I intend to implement dependencies and correct
> un-installation (it does weak pattern matching now).
I don't want to discourage you, because I really, really want you to
improve cargo! That said, I am not convinced of this scheme as laid
out because it adds a lot of pieces without a clearly proportional amount of
win.
How we do dependency resolution looks orthogonal to how we represent the
metadata, and we aren't yet encountering any performance problems in this
area since we only have 2 dozen or so packages.
Do we know how npm organizes its package index? I consider npm to be pretty
rad and would be inclined to do anything that they do.
-Brian
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
