2014-02-02 Thomas Leonard <[email protected]>: > [ I don't want to start another argument, but since you guys are discussing > 0install, maybe I can provide some useful input... ] > > 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 probably have left this part in that formulation by accident. I apologize for that, I had been writing this message in several passes. Yes, of course it does not matter for the developer where he gets build dependencies from, provided these dependencies are readily available for the build process and are easily managed. > > 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. Seems to be a lot of manual work. This could be automated by Rust package/build manager, though. > > 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. Thanks for the explanation, I didn't know that 0install can run build tools and that it could provide the information about libraries locations. This certainly answers my question. >> 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. Again, didn't know that 0install can handle build dependencies. > > 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. Usually build dependencies are a superset of runtime dependencies, aren't they? Nonetheless, this was not about runtime dependencies, this was about general approach. But I think given your explanation of 0install operation this point can be discarded. > > 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. Yes, you're quite correct on that ideally upstream packages should be converted to distribution packages automatically. For the new hypothetical build system I see it like the following: a maintainer downloads sources for a package, invokes some distro-specific tool which in turn invokes `rustpkg` to build the package and assemble dependency information, which is then converted to a distribution package. Then the maintainer manually adds external dependencies to the list. Something like that is already done for Haskell in Arch Linux, for example. It seems that it could be done with 0install, at least, to some extent. >> 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. This is again misunderstanding on my side. For some reason I thought that it is developer who are using that library should specify how it should be resolved. Don't know why I thought so then >_< However, even if only the library owner should write this binding, it is very likely that he won't write 0install package at all. See below. > > 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 This is the biggest problem I see now. 0install could partially provide external dependencies, but not all of them (and I dare say, not even the majority of them, given the number of available 0install packages and comparing it to the number of packages in standard repositories). Then developers and maintainers have to manually track which dependencies are provided via 0install packages and which should be taken from the system package manager. You're correct that this can happen (and will happen) with Rust-only manager too, but I think it is in fact worse than if the list of external dependencies is managed outside of any packaging system because it may give false impression that if everything that the package needs can be provided by 0install. Additionally, it is not clear what will happen if Rust package developers start writing bindings with various distribution packages in their 0install feeds. This could potentially interfere with distribution maintainers, as far as I can see. Given that maintainers would need to convert 0install dependencies to regular dependencies anyway, I think that value of 0install vanishes. We still will have to create some kind of infrastructure for Rust packages (possibly central repository, various conventions, naming (I don't think that multilevel naming system, if we will use some, would interact well with 0install, but I may be wrong again on that), improvements in build system), and all we get if we adopt 0install is highly generic package management which does not take Rust needs into account. Again, given that end users won't see 0install at all, I don't think it is a really good choice. To summarize, I think that it is better to keep Rust package world and external package world completely separate. If they are intermixed, especially with not so widely used packaging system, this will lead to problems. > >> 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. Yes, indeed it does. Thank you very much for your explanation, I don't feel so strongly against 0install now, however, I still think that Rust-only package manager would be much more convenient in long run. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
