Re: Future of OpenLilyLib

[Jean Abou Samra]

Le 21/11/2022 à 22:38, Valentin Petzel a écrit :
> 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.



It is true that not every feature fits. However, in practice, I
have encountered few features that fit neither in an LSR
snippet, nor in LilyPond's core, nor as some kind of mix between
the two where the core receives some generic tools useful for
other purposes as well, while the LSR snippet makes use of these
tools for a very specific purpose.



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


I would change the tense:

[Independently of OLL,] non core developers *are* able to implement
new features with Scheme code that *can* potentially be included in
base LilyPond if proven reasonable.

Don't you agree?



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



I don't think we're very far from that. Include files already work
as kinds of modules. I only see two potential differences between modules
and include files:

- a module should only be loaded once, even if imported twice in
  different locations,

- a module could (optionally?) have its own namespace (Guile module
  object) with private definitions, and only export the definitions
  it needs.

None of these two would be very complicated to add to LilyPond.


> 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).


Yes.

Best,
Jean

OpenPGP_signature
Description: OpenPGP digital signature