Re: Future of OpenLilyLib

[Valentin Petzel]

Hello Jean, Hello All,

I think the main problem with OLL is that it tries to provide some sort of 
equivalent of the STL for Lilypond. Thus is packs a lot of functionality in 
one big chunk that is hard to organize and hard to maintain, feeling like a 
big, alien thing.

In my opinion it is not bad to allow for modular extension of Lilypond, 
especially for things that do not fit the core of the program. You need to keep 
in mind that this would be a strong possibility of enhancing Lilypond without 
cluttering it’s core. And if non core developer were able to implement new 
features in modules that could potentially be included into base Lilypond if 
proven reasonable it might become easier to contribute to Lilypond. This is a 
big part of the reason why languages like python are so popular. But the OLL 
implementation is just unwieldy and hard to maintain.

Currently if I were to develop an OLL module for Lilypond I would face two 
problems: Any potential user first must be motivated to install OLL, which is a 
cluttered and unintuitive process. And then my package would constantly depend 
on OLL being maintained.

Thus I think what would be more sustainable is if we had an module interface 
that is well maintained (eventually to the point of maintaining against 
multiple Lilypond versions), and individual packages using this interface. 
Even more promising would be if Lilypond itself were to allow for modules, 
which would eliminating the need for oll-core at all (also this would even 
allow for more crazy stuff, like packaging specifying code that is executed at 
different stages).

But as it stands I’m not sure if OLL can be maintained. We’ve seen how quickly 
OLL falls if a handful of people fall away, and what we face here is basically 
an uphill battle trying to keep that thing maintained (not even talking about 
further developing it).

Cheers,
Valentin

Am Montag, 21. November 2022, 18:54:50 CET schrieb Jean Abou Samra:
> 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.
> 
> I was going to add my lyrics code to LSR, actually. It's just
> more convenient for users to grab, and it's not like this is
> a very large piece of code that really needs version control
> (although version control in LSR *would* be nice).
> 
> 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.
> 
> 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).
> 
> So it's a shrug from me: I thank you for your effort in making
> the code 2.23.81-compatible, and I'm fine with any reorganizations
> you want to make, but I will always feel that this code is not
> really at home.
> 
> Best,
> Jean
>

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