Hi, Fredrik, Currently a new package manager designed specifically for Rust is under active development. It is called Cargo, and you can find it here [1]. It is pretty much in very alpha stage now, but one day it will become a full package manager and build system for Rust.
[1]: https://github.com/carlhuda/cargo On 07 июня 2014 г., at 23:28, Fredrik Ekholdt <[email protected]> wrote: > Hi! > Seems like this thread has been dead for a while. I am new to rust, but was > playing with it today, looking for rustpkg and ended up reading this thread. > I have tried to read through this thread, but it is possible that there is a > newer more relevant thread covering this topic in which case I excuse myself. > > I am currently working on a language agnostic dependency/package manager and > I was wondering whether it might suit Rusts requirements. Right now we are > targeting it as a replacement to Maven/Ivy on the JVM, but the idea all along > is to make it platform independent (and native) by having a small and > predicable algorithm for resolution. > The resolution engine is written 200 LOCs, and the overall logic (excluding > metadata reading and so on) is about 400 LOCs more. (I wonder if the Rust > implementation will be faster than the one in Scala? :) > > If there is interest I might start looking more into how to port it (I will > need help though) - if not, I guess it was worth a shot! :) > > It is called Adept (https://github.com/adept-dm/adept) and it is in alpha for > the Scala/JVM. The docs (listed below) are still unfortunately a bit > scattered so I am summarising here. > > Some features that might be of interest: > - Fast and reliable resolution of metadata using versioned metadata (which > is easily & safely cacheable). > - Fast and reliable artifact (binary files/sources) downloads, i.e. can > download from multiple sources in parallel. > - Authors can describe compatibility matrixes of their modules. The short > story is that authors can rank modules and thereby define which ones are > compatible (or can be replaced) and in multiple files thereby having many > “series” of compatible modules. Using this scheme we can emulate: “normal” > versioning, (what is called) "semantic” versioning and backward compatibility > matrixes, but also other, more exotic, version schemes as well. AdeptHub (see > below) will make it easy for authors to use the standard ones, but also make > it possible to customise this. > - Adept’s engine is flexible enough so that authors can publish multiple > packages to multiple platforms and based on user input figure out which > package & platform a user should get. > - Adept’s engine is flexible enough to emulate the concept of > scopes/configurations/views so an author can publish different > scopes/configurations/views of the same package: one for compile, one for > runtime, one for testing, etc etc. > - Supports resolution through multiple attributes author-defined attributes. > You can require a specific version, a binary-version, but also “maturity” (or > "release-type”) or whatever other attribute that might be relevant. > - Does not require a user to resolve (figure out which packages you need), > when they check out code a project. The way this works is that Adept > generates a file after resolution that contains all artifacts (their > locations, their hashes, filenames) that is required, as well as current > requirements and the context (which metadata and where it should be > downloaded from). Users/build server will therefore get exactly the same > artifacts each time they build (using the SHA-256 hashes), but using > compatibility matrixes it is possible to upgrade to a later compatible > version easily/programmatically. This file currently called the "lockfile" , > but it is not to be confused with Rubygem lockfiles. Note the name ‘lockfile' > will change of because of this confusion. > - Is decentralized (as Git), but has a central hub, adepthub.com, (as GitHub) > so first-time users can easily find things. > - Decentralization makes it possible for users to change metadata (and > contribute it or put it somewhere else), but also makes it possible to > support a dsl/api in the build tool, where users can create requirements on > build time (version ranges is supported through this). > - Works offline (i.e not connected to the intertubes) provided that > metadata/artifacts is locally available. It knows exactly what it needs so if > something is not available it can give easy-to-understand error messages for > when something is missing (which is different from Ivy/Maven although I am > not sure what the story for cargo or rustpkg was…). > - Supports sandboxed projects reliably (no global/changing artifacts). When > you checkout a project that uses Adept, you can be sure it has the same > artifacts as the one you used on your dev machine. > - CLI-like search for packages (through Scalas sbt, but can be extended to a > pure CLI tool). Works locally and on online repositories. > - Repository metadata is decoupled from a projects source code, which is > feature for me, because you might have different workflows etc etc for source > code and actual releases. > > Stuff we are working on the next weeks: > - Easy publishing to adepthub.com. > - A better web app including browsing and non-CLI searches. > - Online resolution on AdeptHub. > - Notifications for new compatible releases. > - Native web-“stuff" support (i.e. css, js, …) made possible by importing for > bower. This is important for web projects that want 1 package manager for > rust but also wants to use css, js and the like. A common use case for the > JVM, but perhaps less so for Rust? > - AdeptHub will also provide enterprisy features such as support with private > repositories and an on-premise version, which I think is important for > companies to embrace an ecosystem. I guess some might not like this aspect, > but I think this is an important aspect of software development as well. Note > we have put effort into decoupling Adept and AdeptHub from each other and > want an ecosystem similar to Git/GitHub in this regard. > > If you want to read more about it have a look below: (we compare heavily to > Maven/Ivy though) > - Adept’s concepts: > https://github.com/adepthub/adepthub-ext/blob/master/concepts.md > - Adept’s high-level features and a QA: > https://github.com/adepthub/adepthub-ext/blob/master/README.md > > Also here is a programmatic guide (for Scala) which might help you get a > better understanding: > https://github.com/adepthub/adepthub-ext/blob/master/guide.md > > I am more than happy to discuss more details around Adept, rust or just > dependency managers in general - I guess you might see that it is a subject > that is of interest to me. > > > Best regards, > Fredrik > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
