[rust-dev] Cargo requirements

Thomas Leonard talex5 at gmail.com
Thu Jan 26 00:36:09 PST 2012

On 25 January 2012 20:36, Graydon Hoare <graydon at mozilla.com> wrote:
> On 24/01/2012 12:24 PM, Thomas Leonard wrote:
>> Basically, I'd like to make a list of short-comings in existing
>> installation systems that cargo addresses (e.g. poor documentation,
>> too many dependencies, lack of robustness, poor security, etc).
> Summary version: too many concepts and moving parts.
> We kept degrees-of-freedom to a bare minimum with cargo, and there are still
> probably too many. We might well shave more. It's reasonable in 2012 for our
> compiler to support:
>  use foo (url = "git://github.com/user/foo.git");
> out of the box. We don't yet, but we may well do so and remove cargo
> altogether. Developer machines without revision control and internet
> connections in this day and age are curious paperweights.

Thanks for the reply.

Yes, simplicity is a big problem. Unfortunately, all package systems start
simple and grow more complex over time :-(

Embedding the URLs in the code is interesting. How do you see this
working with versions? Would your example above build against the
latest version on foo.git's master?

That might make builds a bit unstable. Would rustc do a "git pull" on
each dependency before building? How would I update my code if e.g.
foo.git made a big API change on master? In the tutorial, I see you
can specify versions. e.g.

use foo (url = "git://github.com/user/foo.git", vers = "1.0");

That works if you don't have diamond dependencies (most systems seem
to start this way). But then what if I have:

use logging (url = "git://github.com/user/logging.git", vers = "1.12.3");
use foo (url = "git://github.com/user/foo.git", vers = "1.0");

and foo has:

use logging (url = "git://github.com/user/logging.git", vers = "1.12.4");

(i.e. a conflict in the version of logging: 1.12.3 vs 1.12.4)

Would it just pick one (like older versions of Maven did)? Or are you
planning to support version ranges? e.g.

use logging (url = "git://github.com/user/logging.git",
                    not-before="1.12" before="1.13");
use foo (url = "git://github.com/user/foo.git",
             not-before = "1.0");

Then you could run a solver to select the best set of compatible
versions. But, I don't see how you can do that if the dependencies are
in the code. For example, if the latest foo depends on "logging >=
1.14" then you'd need to select an older version of foo. Would rustc
check out successively older versions of foo.git, parsing the source
in each, until it found a version that could use a version of the
logger compatible with my program?

> The number of degrees-of-freedom in 0install is much higher, as it's trying
> to solve many more problems (end-user distribution, multi-language,
> multi-transport, multi-vcs, source and executable, OS-packaging, sandboxing,
> etc.)

True. So if I understand correctly:

- Rust will help developers to get the libraries/crates they need to
build, but it's assumed that users already have the run-time libraries
on their machines (or the developer bundles the library with their

- When libraries have language-specific components (e.g.
translations), the developer should bundle all translations of all
libraries with their program, so select-by-locale is not needed.

- Rust will only support Git (note: VCS support is not part of the
core of 0install, but there is a tool called 0release which can
automate the process of making a release from a Git repository).

- Rust will only download source, not binaries. e.g. a Git checkout of
a Rust program will not download rustc, make, etc. If my build uses
e.g. sphinx and graphviz to build its documentation then developers
should install those themselves.

- Rust builds do not need to be sandboxed.

> The critical thing for us to minimize is the cognitive load of figuring out,
> as a developer, how to go from "my new libfoo is in a git repo somewhere" to
> "you can successfully compile 'use foo' in your application". The number of
> steps to achieve this in 0install is simply too high; the publisher has too
> much to figure out and the consumer does too.

True (normally, we don't expect people to depend on a library until
it's been released). Once you have released your new libfoo 1.1,
someone wanting to depend on the new features would update the XML
file in their Git repository from:

   <requires interface="http://example.com/libfoo">
     <version not-before='1.0'/>


   <requires interface="http://example.com/libfoo">
     <version not-before='1.1'/>

> I have to read a number of web
> pages worth of docs and flow charts, and examine a number of XML fragments
> to try to figure which one I am supposed to edit (or create) to make things
> go. That's too much.

Yes. When adding a new language it's not obvious how to do it (and
different languages do it differently). For example, for C programs
depending on a library usually means adding a directory to
PKG_CONFIG_PATH, but whether that would be right for Rust I don't
know. If Rust is putting dependencies in the source code, then you can
target it much more specifically, because you know which individual
source files depend on which library.

> Possibly, as I say, even having the installation-step *be* a separate tool
> is too much. Shaving down interaction-steps is really important. People
> don't have a lot of time to learn how new systems work.

Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

More information about the Rust-dev mailing list