[rust-dev] Cargo requirements

Graydon Hoare graydon at mozilla.com
Mon Jan 30 16:22:54 PST 2012

On 1/26/2012 12:36 AM, Thomas Leonard wrote:
> Thanks for the reply.
> Yes, simplicity is a big problem. Unfortunately, all package systems start
> simple and grow more complex over time :-(

All systems of any sort start simple and grow more complex, yes. But one 
sometimes "starts new" to see what level of complexity is legacy and can 
be safely discarded. We live in a world with pervasive distributed 
version control now. We didn't used to.

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

By relating to tags stored in foo.git, probably.

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

No, we very specifically built the versioning scheme in our crates to 
permit loading and using multiple versions of a library in the same 
binary (with a deterministic, acyclic dependency graph). IOW the 
"diamond" doesn't have a join point unless they're metadata-equivalent 
versions. This is baked into rust's library name-mangling scheme.

> 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");

You wind up with two copies of logging in your process, and they don't 
conflict because all their names are version-qualified and there are no 
singletons or global (unless you do unsafe things; don't do that). This 
is what we built already.

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

One or the other, yes. Use of a package manager that does anything other 
than self-contained blobs is actually the minority case for end-user 
software these days. I know the linux ecosystem makes it seem otherwise, 
but it's a minority case.

Of course, we don't intend to *prevent* people from using 
package-managers to package up rust crates either. And if they can 
handle multiple library-version side-by-side installs (say, apt or 
whatever) then more power to them.

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

Some package managers understand system-level locales. For those cases, 
devs will likely try to integrate with the locale system on their OS. 
Others don't, and you have to just ship multiple downloads, like so:


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

We'll start with git and grow others as needed. If we need any.

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

More or less. We're ok having an event horizon beyond which the rust 
compiler or cargo can't (and doesn't try to) manage "the world" around 
it. It probes, tries its best, and complains if it fails.

This is, to some extent, always going to be true. For any tool. You have 
a threshold beyond which 0install doesn't try to manage your target 
system either. It can't do everything. We're just doing less.

Which, for a young language, is actually good. It makes our devs more 
likely to do *some* automated code-sharing, by keeping the activation 
energy of using-the-automation low. Appropriately low for the ambitions 
involved. A lot of people are still writing hello world with rust.

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

Yes. We baked metadata, version linkage specification and management 
machinery into the language, to some extent, to mitigate this misery. I 
mean, Rust is already rare in that it:

   - specifies a unit of compilation, versioning and linkage
   - requires names to be scoped within such units, never global
   - requires that such units form an acyclic dependency graph

This is all intentional. We've seen the disastrous results of trying to 
manage deployments of C/C++ and java programs in the wild under ad-hoc 
linkage, distribution and dependency regimes. C# / CLR did a bit better. 
We're hoping to do better still, but we'll see. It's very delicate.

I don't pretend to have "solved" all these problems, I just don't feel 
like adopting 0install (or any other system I've seen) is likely to help 
solve it any more than it is likely to drive people away by the feel of 
overengineering, adding extra moving parts. The moving parts we added to 
the language had to be *very* minimal to pass the developer sniff test. 
We're probably *still* going to get push-back from people who see the 
optional (disambiguating) UUIDs in our crate metadata and start having 
flashbacks to XPCOM.


More information about the Rust-dev mailing list