[rust-dev] Deprecating rustpkg

Fredrik Ekholdt freekh at gmail.com
Sat Jun 7 12:28:59 PDT 2014

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,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140607/db5313f6/attachment.html>

More information about the Rust-dev mailing list