[ I don't want to start another argument, but since you guys are
discussing 0install, maybe I can provide some useful input... ]
On 2014-02-02 07:20, Vladimir Matveev wrote:
How will it handle external dependencies?
I don't think it should. External dependencies are way too complex.
They come in different flavors on different systems. On Windows, for
example, you don't have a package manager, and you'll have to ship
these dependencies with the program using an installer. On each Linux
distro there is custom package manager, each having its own strategy
of naming things and its own versioning policy. It is impossible to
unify them, and I don't think that Rust package manager should attempt
to do this.
I don't understand this. A package manager specific to Rust is
additional software, just like 0install. 0install has full support for
installing dependencies via the system package manager on many systems
if desired.
*End users* won't need Rust package manager at all (unless they want
to install development versions of Rust software). Only package
maintainers and developers have to use it. End users just use their
native package manager to obtain packages created by maintainers. If
Rust would depend on zero install, however, end user will be *forced*
to use zero install.
I don't follow this. Whether the developer uses 0install to get the
build dependencies doesn't make any difference to the generated binary.
Of course, you *can* distribute the binary using 0install too, but
you're not required to.
I'm against of using zero install for the following reasons. First, it
is just a packaging system. It is not supposed to help in building
Rust software. But resolving build dependencies and invoking the
compiler with correct paths to installed dependencies is crucial.
How, for example, zero install would handle dependency to master branch of
some source repository?
0install doesn't automatically check out Git repositories (although that
would be handy). Here's how we currently do it:
- Your program depends on libfoo >= 1.0-post
- The latest released version of libfoo is only 1.0
- You "git clone" the libfoo repository yourself and register the
metadata (feed) file inside it:
$ git clone git://.../libfoo
$ 0install add-feed libfoo/feed.xml
- 0install now sees that libfoo 1.0 and 1.0-post are both available.
Since your program requires libfoo >= 1.0-post, it will select the
Git checkout version.
> What if I'm developing several packages which depend on different
versions of the same package? Zero install allows
installing multiple versions of the same package, yes, but how should
I specify where these libraries are located to the compiler?
Given a set of requirements, 0install will tell you where some suitable
versions of the dependencies are. For example:
$ cd /tmp
$ git clone https://github.com/0install/hello-scons.git
$ cd hello-scons
$ 0install download Hello-scons.xml --source --show
- URI: /tmp/hello-scons/Hello-scons.xml
Version: 1.1-post
Path: /tmp/hello-scons
- URI: http://0install.net/2006/3rd-party/SCons.xml
Version: 2.0.1
Path:
/var/cache/0install.net/implementations/sha1new=86311df9d410de36d75bc51762d2927f2f045ebf
- URI: http://repo.roscidus.com/python/python
Version: 2.7.6-1
Path: (package:arch:python2:2.7.6-1:x86_64)
This says that the build dependencies are:
- This package's source code (in /tmp/hello-scons)
- The SCons build tool (which 0install has placed in /var/cache)
- Python (provided by the distribution)
The source could also specify library dependencies. How do you get this
information to the build tool? The usual way is to tell 0install how to
run the build tool in the XML. In this case, by running SCons on the
project's SConstruct file.
But you could get the information to it some other way. For example, a
"rustpkg" tool that invokes "0install download ... --source --xml"
behind the scenes and does something with the machine-readable
selections document produced.
How should I specify build dependencies for people who want to hack on my
package?
List them in the XML file that is in your project's source repository.
Users should then be able to clone your git repository and build, with
build dependencies handled for them.
Majority of direct dependencies will be from the Rust world,
and dedicated building/packaging tool would be able to download and
build them automatically as a part of build process, and only external
dependencies would have to be installed manually. With zero install
you will have to install everything, including Rust-world
dependencies, by yourself.
0install should be able to handle all build dependencies (e.g.
libraries, the Rust compiler, build tools, documentation tools, etc).
Second, it is another package manager which is foreign to the system
(unless the system uses zero install as its package manager, but I
think only very minor Linux distros have that). Not only this is bad
because having multiple distribution systems is confusing for the end
users (BTW, as far as I can see, both Linux and Windows users don't
want it. Linux users wouldn't want to have additional package manager,
and majority of Windows users just don't know what package manager is
and why they have to install some program which downloads other
programs just in order for them to use this small utility. They are
used to one-click self-contained installers. On Android you are forced
to have self-contained packages, and zero install won't work there at
all.
This is all about run time dependencies, but I think the discussion here
is about build time, right? You'll have the same issues with any system.
> Don't know anything about Mac, haven't used it). It also means
additional impact on distribution maintainers. If Rust adopts zero
install universally, then, because distribution maintainers won't
support any build system but their own, they will have either to
abandon Rust software at all or build and resolve their dependencies
(including Rust ones) manually, as it is done with C/C++ now. They
won't be able to use zero install because they simply can't depend on
it. I think this will hurt Rust adoption a lot.
I think any build tool (including go, cabal, pip, rustpkg) will have
this problem. Ideally, you want distributions to be able to turn
upstream packages into their preferred format automatically. Whatever
system you settle on this should be possible, as long as you have some
kind of machine-readable dependency information.
Zero install may have integration with package systems, but looks like
it is very brittle. According to [this
page](http://0install.net/distribution-integration.html) it is package
owner's duty to specify how native package dependencies should be
resolved in each distribution. This is extremely fragile. I don't use
Debian, for example, how would I know how my dependency is called
there? When package owners won't write these mappings for every
distribution, then this integration immediately becomes completely
pointless. Also I'm not sure that zero install can integrate with
every package manager it supports without additional tools, which
means even more unneeded dependencies.
To be clear, it's the upstream of the library who specify what their
library is called on each distribution. As a user of the library, you
don't need to care.
If upstream doesn't specify the native package name, then it just means
0install will download the upstream version rather than using the
distribution's copy (which would be more efficient). Distributions can
also specify the association at their end, although they generally don't
bother.
Zero install package base is also very small. Distributions usually
provide a lot more packages. Then, if zero install is the only way
Rust software is packaged, I just won't be able to use these libraries
unless someone, possibly myself, writes a zero install package
definition for it. And this is extremely bad - I don't want to resolve
transitive dependencies for my external dependencies, this is already
done by my distribution maintainers.
You mean that you might want to depend on a non-Rust package (e.g.
python-sphinx) for your build, but 0install won't be able to provide it
for you? That could happen, although
a) it's no worse than when using a Rust-only package manager
b) you have the option to make it work by writing a little XML
Having custom flexible build and packaging system which is used by
developers and maintainers is a separation of concerns with very clean
interfaces between software developers and software users. I believe
that it should be created in order for Rust to be adopted at large,
and rustpkg provides solid base for it.
I hope the above has clarified things a bit.
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
