Hi, one of the results of yesterday's developer meeting in Salzburg [someone™ should provide a more concise summary than the notes in the GoogleDoc] was that I should go forward "integrating openLilyLib" as LilyPond's official extension mechanism.
I spent my travel back home reading through the code and writing a few
summaries and drafts etc., and while doing so I came to the conclusion
that the actual task, i.e. what has to be done "now" is surprisingly
(not to say, disappointingly) small.
I think it is best to start a discussion without looking at the current
implementation at all, so any issues (architecture considerations or
coding critique) with the existing oll-core code base won't distract us
from the conceptual perspective. So I wrote up a very short summary of
how I think an extension system should look like and what initial steps
there are to be taken. If anything is unclear or needs more factual or
conceptual detail I'll of course happily expand on it.
For reading convenience I attach a PDF version, but for inline
commenting the text below should be better.
Best
Urs
## Current State
* openLilyLib is a set of extension packages, providing high-level
functionality
* `oll-core` provides the basic interface and implements required and
additional functionality.
## Overall Outline
* Relevant functionality will be moved from `oll-core`
to LilyPond proper, providing the main extension mechanism
as well as some of the additional functionality (option
handling, logging ["oll:" function to report status and errors]).
* The extension mechanism provides the commands `\loadPackage` and
`\loadModule`, and it allows configuration options to be passed to
either. It also handles package dependencies and implicit loading.
(one example for using options (just for getting an idea) would be
\loadPackage \with { modules = annotate.choice } scholarly. )
* This will *not* be called openLilyLib anymore (but "is" LilyPond's
unnamed extension mechanism).
* 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.
* openLilyLib will remain similar to what it is now, a curated
collection of standard packages that are not mature enough or too
specific to be included in LilyPond itself. The extension mechanism
will find openLilyLib packages through LilyPond's search path.
* Packages can be stored anywhere on disk (=> LilyPond search path),
so on the long term it may be interesting to set up an uncurated
package manager like npm or CTAN/TeX Live.
* Frescobaldi will provide a user interface to manage extensions but
also for using them in documents (e.g. it will know about available
configuration options and provide an action (context menu/dialog)
to use a given package).
roadmap.pdf
Description: Adobe PDF document
