Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 20:02, Mark Knoop a écrit :
> Thanks Jean for your thoughts, which are not so far from my own. A few comments:
>
> > Maybe what I'm going to say will sadden some, but personally,
> > I never quite understood what the advantage of developing
> > openLilyLib as a library external to LilyPond, as opposed to
> > contributing features to LilyPond itself, was supposed to be.
> Having just looked through quite a lot of the code in openLilyLib, I
> think there will always be code there that is not suitable for inclusion
> in LilyPond, for many reasons (highly specialized use cases, code which
> works just-well-enough™, etc...).
>
> It's no criticism of the core LilyPond developers to acknowledge that
> not every desired feature will be accepted, and even if so, there is
> still a significantly higher hurdle to contributing to LilyPond than to
> OpenLilyLib (and rightly so).



That is true. On the other hand, the hurdle for contributing to
LilyPond is already significantly lower than it used to be a few
years ago (we migrated to GitLab, large parts of the contributor's
guide were rewritten, ...).

It's all a tradeoff. The less requirements you put on quality,
the more maintenance trouble you get (and there is an inherent
maintenance trouble related to the fact that OLL is not usually
constrained to a single version of LilyPond, although you are
proposing to make it so in the short period until 2.24).



> Almost all programming languages have non-core features which are
> developed in a modular way - this fact would seem to support the case
> for something similar for LilyPond.



A Python library for scientific computing has absolutely nothing
to do with a Python library for creating web pages, so the developers
have no reason to tie themselves together. In contrast, music
typesetting is an intricate task with dependencies everywhere.



> I see two advantages over LSR, the primary one being version control
> (which includes being able to search it locally with git grep); the
> other being the potential to include code which is larger in scale and
> interacts sensibly. (Once you start importing several LSR snippets into
> one project, the potential for adverse side-effects becomes > 0.)



I dream of a remake of LSR that would fix its problems (lack of
history / version control, LSR editors don't know who submitted
a snippet and are not notified about it, things like that).

On the other hand, when I see a large snippet of useful code,
my first reaction is normally to wonder how some of it could
be turned into a patch.



> > To be honest, although I wasn't there at the time, it is my
> > impression that this split was partly motivated by some personal
> > conflicts that reduced Urs' willingness to submit patches to
> > LilyPond, which is not relevant for us today.
> Indeed, this isn't relevant, except to acknowledge that for whatever
> reason, there is at the moment a bunch of useful stuff which is a) not
> yet in LilyPond, and b) bit-rotting until it is dealt with.


Yes.


> > Some of the OLL stuff has been made part of LilyPond over the
> > years, for example Merge_mmrest_numbers_engraver and \vshape.
> > There is also \staffHighlight, which serves a purpose that
> > overlaps a bit with the purpose of AnaLYsis. Long-term, I would
> > like to see edition-engraver go that route as well (with a
> > better, iterator-based implementation).
> Absolutely I'd also love to see this. (Another task which I didn't put
> in my first email is to clean out code that *has* made it into LilyPond.)
>
> Whilst I was able to fix-up the edition-engraver for Guile 2, I am
> certainly not up to rewriting it "better" - and I don't expect anybody
> else to do that either.



Iterators are currently not Scheme-accessible anyway. It would
have to be done on the C++ level.


> My hope is that by making OLL a little more usable and less chaotic, it
> might be possible to identify firstly which features are being most
> used, and secondly use that information to prioritize moving those into
> LilyPond in the best way possible.


Good.

Best,
Jean

OpenPGP_signature
Description: OpenPGP digital signature