Re: Extension management, first sketch

[Urs Liska]

Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> * A core extension library shipping with LilyPond will be initiated. 
>   Extensions that are considered core functionality (prime
> candidates:
>   edition-engraver, stylesheets) will eventually be moved here from
>   openLilyLib, additionally special functionality (e.g. gregorian.ly,
>   arabic.ly) may over time be moved there to expose the difference
>   between core functionality and use-case specific modules more 
>   clearly. These tools will then be called through `\loadModule`
>   instead of `\include`, which will be easy to handle with
>   convert-ly rules. Probably it would be a good idea to eventually 
>   expose *all* non-standard notation through explicit packages
>   and have that nicely describe in the LM. This too will not be
>   called openLilyLib.

Thinking about it I would go one step further:

Currently we have a /ly folder in the installation which contains core
files like music-functions-init.ly on the one hand, and on the other
hand optional files that users can \include for specific functionality,
such as the ones I have given as examples above.

I think now that *all* the files that are not included unconditionally
but only upon user request should be treated as packages. This will
make the code structure clearer, since there is a clear distinction
between the files LilyPond needs/uses for its startup (then *all* files
in /ly) and optional files at the user's disposition.

Urs