[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: some questions about GUIX

From: Ricardo Wurmus
Subject: Re: some questions about GUIX
Date: Tue, 29 Dec 2015 20:11:55 +0100
User-agent: mu4e 0.9.13; emacs 24.5.1

Sam Halliday <address@hidden> writes:

> Ludovic Courtès <address@hidden> 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

> 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:
> 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:
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]