[rust-dev] Deprecating rustpkg

Kevin Cantu me at kevincantu.org
Sat Jun 7 13:27:33 PDT 2014


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 <dpx.infinity at gmail.com>
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 <freekh at gmail.com> 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
> > Rust-dev at mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev
>
> _______________________________________________
> Rust-dev mailing list
> Rust-dev at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140607/2649667c/attachment.html>


More information about the Rust-dev mailing list