Re: packaging lilypond as a docker container?

[Jonas Hahnfeld]

Am Dienstag, den 21.01.2020, 02:38 -0600 schrieb Karlin High:
> On 1/21/2020 1:49 AM, Han-Wen Nienhuys wrote:
> > if GUB is used, who is maintaining and/or working on it?
> 
> Almost exactly a year ago, there was a sizable "Please test gub" effort 
> initiated by Knut Petersen.
> 
> <
> https://lists.gnu.org/archive/html/lilypond-devel/2019-01/msg00221.html
> >
> 
> Clear instructions were given for exactly how to test GUB, and just that 
> thread seems to have involved about 16 people.
> 
> More recently, it looks like Jonas Hahnfeld's work with Python 3 
> migration involved quite a number of changes to GUB.

Yep, and it's not been a very pleasant experience. To be precise here:
It's not about porting GUB to Python 3, it's just that porting LilyPond
will introduce a dependency on an updated package for the next release.
So while David is mostly correct that contributors don't need to bother
with GUB, that doesn't hold true once you want to bump one of its
dependencies...

Based on this experience, I've thought about how to improve the process
of building binary releases for LilyPond. What I have been
experimenting with is a set of portable shell scripts that build mostly
static executables. I've a prototype ready at 
https://github.com/hahnjo/lilypond-binaries which works for Linux and
FreeBSD. I don't see a reason it cannot work on macOS, but I don't have
the possibility to test...

>  From the notes I've kept, Jan Nieuwenhuizen proposed replacing GUB with 
> something based on Guix.
> 
> <
> https://lists.gnu.org/archive/html/lilypond-user/2016-09/msg00690.html
> >
> 
> That idea was mentioned a few times since, but I can't recall if 
> GUB-replacement discussions have moved beyond that or not.

As far as I understand, Guix is a package manager in the first place.
In the thread Jan proposes to use it for cross-compilation, which I
think is the primary reason for the complexity in GUB. So why go that
route once more?
Instead I designed the mentioned scripts such that they produce native
executables. That's also how TeXlive builds their packages, for
example, and it works quite well if you compile on the oldest OS that
you intend to support (CentOS 7, FreeBSD 11).

I haven't decided yet how to compile for Windows. Maybe that's still a
valid use case for cross-compilation (but only with a very limited
scope). I'm not going to tackle this until we've switched to Python:
Then we can just use the embeddable zip file provided by the Python
project without bothering with cross-compilation for this beast.
Everything else (Guile etc.) worked without problems in my early tests.

If this attempt sounds interesting to the community, I would be happy
to submit the scripts for inclusion into the LilyPond repository
itself. That would also solve another issue with GUB: Currently it's a
separate repository with no way to keep it in sync with changing
dependencies for LilyPond...

Regards,
Jonas

P.S.: to come back to the whole container idea: after you have the
binaries, you can of course build a docker container from them...

signature.asc
Description: This is a digitally signed message part