[Top][All Lists]

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

Re: Address output-distance problems: (issue 563730043 by address@hidden

From: Kevin Barry
Subject: Re: Address output-distance problems: (issue 563730043 by address@hidden)
Date: Thu, 12 Mar 2020 17:35:46 +0000

> I say that having a developer monoculture doesn't buy as anything since
> we still need to provide for a multitude of users.

We are talking about testing builds right? If a user gets as far as "I need
to test changes I made to the source code" then surely it would be better
to have something to point them to than to say "let's see if one of the
devs ever ran into the same problem you are having".

It also means we could have some confidence when figuring out if a problem
is environmental or not.

Having some kind of official dockerfile isn't pushing a monoculture: it
actually makes it easier for people to run whatever OS they want and not
have to keep it in line with LilyPond build requirements. It would make
building on Windows or MacOS easier since there are prepackaged docker apps
for both.

> > Installing docker and building an image is much easier than setting up
> > a working build environment for LilyPond now.
> Get a LilyPond source .deb and do sudo apt build-deps on it.  Afterwards
> you have a working build environment.

That would not work on my system. Making everyone use .deb is another kind
of monoculture.

> I don't really see the underlying logic.  Users should consider it a win
> when the developers state "you are no longer allowed to run LilyPond
> natively, get a docker container", and you want to convince developers
> to stop using and developing LilyPond natively on their systems because
> it will be so much easier to maintain a virtual layer in between?
I wouldn't ever suggest that we make running LilyPond require docker. I
thought this discussion was about testing builds.

> We have had the LilyDev VM for a long time now.  It has seen some use,
> but not overwhelmingly much, and the reasons for that are pretty much
> the same for newer virtualisation methods.
I disagree. The docker image specification could be a simple text file that
is kept in the LilyPond repo, and people can build it if they want. Tests
could build it and use that image for testing, etc, etc.



reply via email to

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