Create a central package database and website with all the trimmings #10041
Comments
|
This will likely incorporate or replace http://docs.octayn.net/ and http://rust-ci.org/rust-ci/ |
|
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. |
|
It'd be cool to integrate benchmark graphs with test run data, and view how it changes over time. |
|
1.0, high |
|
Let users vote on existing packages would be help to find great packages. See reddit and stackoverflow. |
|
+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. |
|
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. |
|
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 |
|
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! |
|
cc #1642 |
|
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. |
|
@visionmedia what security model are you using? On Thursday, January 23, 2014, TJ Holowaychuk [email protected]
Tony Arcieri |
|
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 |
|
@visionmedia I'd suggest checking out TUF which I mentioned earlier: http://theupdateframework.github.io/ |
|
@tarcieri will do |
|
@visionmedia: Please keep in mind that Zero Install is an existing solution to build on with features like package signing and integration with system package managers. It handles side-by-side installation of multiple versions fine too. |
|
@thestinger I'm not familiar with Zero Install - http://0install.net/? Not quite what I had in mind but feature-wise it seems pretty complete. |
|
Yes, that's it. I became familiar with it when Rust was considered as a possible language for the rewrite. Rust is of course nowhere near stable enough yet, and the ultimate decision was OCaml. |
|
cc me; |
|
I don't think we should reinvent the wheel. Do we want to deal with issues like package signing and handling dependencies in other languages ourselves? That's why I'm pushing for 0install as it's already a full solution with existing usage. Rust just needs to layer on some Rust-specific sugar. |
|
Yes, or as suggested fork npm or pypi. |
|
How do they compare to Zero Install? I think we have some hard requirements:
As a bonus, Zero Install gives us...
|
|
IMO reinventing the wheel isn't so bad when that wheel is a lot nicer to use than the last wheel. Definitely -1 for npm fork for me. |
Interesting point is the implementation: centralized or decentralized? @visionmedia to be honest, not really sure what is the state-of-the-art of package management, and I'm a sucker for ideas like your versions.io (is it on github?) |
|
I have github.com/versions, I'll push the code up soon if I have some more time to hack on it. I'm definitely a sucker for first impressions, so I'd like to get the API as nice as I can. Each "platform" can store arbitrary metadata per package so it should facilitate the needs of most of these different languages/systems, basically a glorified S3 with auth/signing/org/search etc. I think storing the packages in S3 would be good, we've had issues with both github and npm being down, and while S3 isn't perfect it holds up pretty well, and using a pluggable store would make it trivial for people to fork this thing and boot up a private instance. There's definitely pros and cons of centralized / decentralized, though personally I think decentralized is covered just fine already, it's easy to write a package manager that just supports tarballs/git etc, but then it's really annoying when someone's site goes down, or you're trying to find where the damn package lives and find out it it's in bitbucket or something annoying to work with haha |
|
I think we should be careful not to over-engineer this. For example, why store packages in S3, or separately at all? Git supports versioning (via tags), signatures, generating tarballs (git-archive), and mirroring (obviously). Find a decent Git host -- hey, don't we have GitHub? -- and we get all these features for free. If you're a "sucker for first impressions", then the fact that Git does all this already should ring alarm bells. If people are tagging their versions, signing their commits, maintaining mirrors already, then why would they care if some magical package manager does it as well? What would really impress them (and me) would be if the program determined the version automatically, based on existing tags -- which is exactly what rustpkg does. Maybe even silently switch to a mirror when the main site goes down. We want less work for ourselves, not more. If our solution ends up just a thin layer around existing tools, that's a good thing. Let's not forget that. |
|
Nominating for removal from milestone. Cargo is not a 1.0 blocker, neither is this. |
|
Removing from 1.0 milestone; leaving at P-high. |
Fix new_return_no_self with recursive bounds Fix rust-lang#10041 This uses a hash set, as described in rust-lang/rust-clippy#10068 (comment) changelog: [`new_return_no_self`]: fix stack overflow when the return type is `impl Trait` and contains recursive bounds
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.
The text was updated successfully, but these errors were encountered: