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