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