Create a central package database and website with all the trimmings

[brson]

As part of the Rust user experience we need package discovery to be very easy. Let's make a single place to find packages, docs, metrics, and whatever else is important.

Let's try not to require a lot of dynamic content, and instead rely on other services like Travis CI and GitHub pages wherever we can. Dynamic web sites require operational support that makes them much more difficult to set up and maintain.

Just copy http://npmjs.org.

cc #9875

Nominating.

[brson]

This will likely incorporate or replace http://docs.octayn.net/ and http://rust-ci.org/rust-ci/

[emberian]

docs.octayn.net was a "it's the weekend, let's procrastinate homework with something useful!" project. it just fetches and runs rustdoc on a bunch of repos.

[emberian]

It'd be cool to integrate benchmark graphs with test run data, and view how it changes over time.

[brson]

cc #1453 #1642

[catamorphism]

1.0, high

[liigo]

Let users vote on existing packages would be help to find great packages. See reddit and stackoverflow.

[gsemet]

+1, love this idea. How will this integrate if the developer environment? and how will dependencies be distributed along with the software? For instance, pip install everything in /usr/, or in the virtualenv if used. However, one might want its dependency project for development and only distribute the binary. How about versionning? It's a field where I have lot of idea and some experience (in python, C++, a little bit of java), and I always wanted to do something for my C++ projects, but maybe rust is the place to do something :) I really like the simplicity of pypi, and hated the complexity of maven and generally all java-related dependency management tools.

[runvnc]

I think you can release a central database and website without fully implementing dependency management and package versioning, and I hope you will.

I think the first step is to link to the wiki or Travis CI page on the top of the Rust home page, and that would have saved me about six or seven minutes.

Anyway I am currently primarily a Node.js user. I think that the node/npm semantic versioning and dependency management (http://semver.org/, https://github.com/isaacs/node-semver) is the state-of-the-art, and I hope that Rust will consider adopting something similar.

I am pretty excited about Rust, even more so than Go, because of the straightforward syntax, type inference, performance, low-level capabilities, etc. I think that semantic versioning and dependency management similar to Node/npm would make Rust the obvious choice for many types of server-side development.

But I think that semantic versioning/dependency management is so complex that it at least deserves its own issue.

[thehydroimpulse]

I agree with @ithkuil, in that Rust should take some ideas from Node in terms of NPM. I think having a local, by default, install path would be best. Maybe under $PWD/.rust/crates or something. Something akin to node_modules. I think those systems who adopted a global install path, by default, made things much harder in the end.

[tarcieri]

I would strongly suggest looking at The Update Framework:

http://theupdateframework.github.io/

It provides a set of metadata formats (based off of JSON) upon which you can implement secure software update systems.

It's designed to provide secure code signing with multisignature trust in a way that developers can opt-in to signing their own packages, otherwise they're signed automatically by the update system. This makes it unobtrusive while still providing good security guarantees.

I have been working on implementing it as part of RubyGems. It's also being integrated into PyPI. I'd be interested in working on an implementation for Rust too!

[brson]

cc #1642

[tj]

FWIW I'm building a tool called versions.io that will remove the need for people to keep re-inventing package management solutions. They're all effectively identical, so I'd like to house them under one roof, so versions.io will have the concept of platforms built right in (some packages can be shared between multiple), and we'll have organization support and tight github integration. Backed by s3 it will be much more robust than npm etc, no need to copy all of that. If anyone finds that appealing I'd love to collaborate and take suggestions!

It's worth noting that you could still have say crates.rust-lang.org CNAME rust.versions.io, so from a "branding" perspective it wouldn't be a loss either.

[tarcieri]

@visionmedia what security model are you using?

On Thursday, January 23, 2014, TJ Holowaychuk notifications@github.com
wrote:

FWIW I'm building a tool called versions.io that will remove the need for
people to keep re-inventing package management solutions. They're all
effectively identical, so I'd like to house them under one roof, so
versions.io will have the concept of platforms built right in (some
packages can be shared between multiple), and we'll have organization
support and tight github integration. Backed by s3 it will be much more
robust than npm etc, no need to copy all of that.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10041#issuecomment-33130674
.

Tony Arcieri

[tj]

I'm not far into the project yet, just started the API/s3 integration a few days ago, certainly open to suggestions! I'd like to also facilitate pre-compiled attachments for releases, but that's probably more applicable to executables and addons for platforms like node/ruby