[rust-dev] Cargo requirements

Graydon Hoare graydon at mozilla.com
Wed Jan 25 12:36:27 PST 2012

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.

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.)

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. 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.

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.


More information about the Rust-dev mailing list