On 25 January 2012 20:36, Graydon Hoare <[email protected]> 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 program). - 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> to <requires interface="http://example.com/libfoo";> <version not-before='1.1'/> </requires> > 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 _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
