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:
http://www.mozilla.org/en-US/firefox/all.html
- 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.
-Graydon
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
