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@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
