From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: some questions about GUIX Date: Tue, 29 Dec 2015 20:11:55 +0100 Message-ID: <87a8otax38.fsf@elephly.net> References: <87d1ttmdbd.fsf@gmail.com> <87a8ot47wr.fsf@gnu.org> <87vb7h1cwh.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:53040) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDzgm-0007DQ-3J for help-guix@gnu.org; Tue, 29 Dec 2015 14:12:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDzgh-00034f-3D for help-guix@gnu.org; Tue, 29 Dec 2015 14:12:08 -0500 In-reply-to: <87vb7h1cwh.fsf@gmail.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Sam Halliday Cc: help-guix@gnu.org Sam Halliday writes: > Ludovic Courtès writes: >>> * Integration with existing software distribution managers >>> >>> How are you planning on handling these more modern languages that >>> manage their own dependencies? >> >> Currently, we import those languages’ dependency trees into the Guix >> dependency tree, and so some additional QA (make sure tests pass, >> provide adequate licensing info, descriptions and synopses, etc.) > > OK, I'm not entirely sure what that means for JVM / Maven Central > applications but it sounds like you're doing something sane. > > The important thing for JVM applications is that each jar doesn't end up > getting tracked as a separate entity, because that just makes it > infeasible and painful to package anything through the official > channels. I’m not sure I understand what you mean here. I have been packaging a couple of Java things and the reliance on prebuilt jars and Maven causes quite a few problems. This is the single most important reason why there isn’t much of Java to be found in Guix yet. Building a full non-trivial Java application from source without resorting to some black box jars along the way is very difficult. I’m still working on slowly packaging the dependencies of log4j, one jar at a time, ... and I even forgot why I’m working on log4j because the dependency graph for an arbitrary Java package is overwhelmingly large. (We have a minimal Ant, though, and I just finished abstracting an ant-build-system, so packaging is already becoming a little easier and considerably faster.) We are building library for library as individual packages in Guix. We certainly won’t bundle prebuilt jars from Maven if it can be avoided at all. > The main problem I want to avoid is the situation where it can take > longer to package a small application than it does to write it. This depends a lot on the development culture fostered by the language community. For R packages, for example, packaging is almost trivial. With the CRAN importer I created Guix package expressions from (almost) all packages on CRAN within minutes. Now I just have to look through the stash for packages that I want to submit to Guix upstream, build them and that’s it. For Java, however, it is definitely true (for now) that packaging an application can certainly take longer than writing one from scratch in a different language. This is largely due to the fact that Java programmes are rarely ever built from source (recursively) as Maven conveniently takes care of downloading binary artifacts. I suppose we could have a Maven importer in due time that converts the information contained in pom.xml files to a Guix package expression. We won’t have to be using Maven itself. This would make packaging Java libraries and applications about as easy as it is now to package R packages from Bioconductor or CRAN. >> Guix’s build daemon uses containers to perform isolated builds: >> >> http://www.gnu.org/software/guix/manual/html_node/Features.html > > Interesting. I wonder if you wouldn't benefit from a docker / drone > network, just as a distribution mechanism for your own build farm. It > would be a shame to expend effort on that since it is somewhat something > of a solved problem (and purely a DevOps matter, not a user concern). Work is under way to distribute build artifacts over GNUnet. Currently it is already possible to share build results over HTTP. Ideally, package building is a distributed effort. (We aren’t there yet.) >>> * Issue tracker / comm channels >>> >>> Will you be continuing to use debbugs, savannah and mailing lists going >>> forward or would you consider moving to a modern community management >>> system like gitlab? >> >> I hear the appeal of GitLab and the like. However, as was recently >> discussed on guix-devel, while I think we must find ways to improve our >> workflows (for instance, tracking patches is becoming tricky), I don’t >> see us moving to one of those web-based approaches for several reasons: >> >> https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00429.html > > I've never used GitLab, but I understand that it is free software. The > thread above seems to suggest that it is proprietary. There are two variants AFAIU; the hosted GitLab service uses the proprietary version. Although I personally started contributing to free software projects regularly only at the time when Github came around (before that it was quite awkward for me to send patches via email), I have come to really appreciate the mail-based workflow we have for GNU projects. Savannah certainly isn’t pretty (and I only used the web interface once or twice to get the info I needed to get started), and I find debbugs somewhat hard to use, but I think using mailing lists for discussing patches (but not to keep track of them) is vastly superiour to the workflow imposed by Github and similar systems. ~~ Ricardo