Further historical disambiguation: * there used to be no package manager * Cargo was created * rustpkg replaced Cargo * Cargo' replaced rustpkg
Why I'm the only one who calls it Cargo', I don't know. ;D Kevin On Sat, Jun 7, 2014 at 12:38 PM, Vladimir Matveev <[email protected]> wrote: > 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 >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
