A convert-ly like tool for openLilyLib

[uliska]

We have started to set up a unit test infrastructure based on automated build tests. One motivation for this was that changes in a library might break code in other, depending libraries.

Of course such changes also break user code. LilyPond itself has the convert-ly tool letting users update their documents (mostly) automatically, and I think we should have something like this for openLilyLib too.

First step is to create an infrastructure for library versioning. GridLY started announcing version numbers, although still simply by announcing. I think we should find a canonic way to force libraries to have a version number, presumably integrated in (or derived from) openLilyLib's option handling. Then we should make it possible (or necessary) that user code names the library version it expects to use. This could be done by either providing a new command or modifying \loadModule so you'd pass along the library version, e.g. \loadModule "gridly" 0.4.0 (the latter being a list? argument).

Once this is in place openLilyLib or a standalone script are able to check if the loaded library version matches the expected one.

Then we should think about possible tools to handle the situation. So far I have two ideas about it:

Using convert-ly

Maybe it would be possible to

• write a file defining convert-ly rules for our libraries
• Change convert-ly to accept that file as argument so it would simply add our rules to its existing ones.

However, I see one problem with this approach. Other than with the usual case where you use convert-ly we can't simply update one arbitrary file. Loading a library happens in any file in the include structure of a document, and when passing an arbitrary file to convert-ly this can't be reflected in any way: An arbitrary file doesn't (easily) know if there is an include somewhere that would have to be considered, and when processing the file that actually contains the include we don't know which files depend on this.

Therefore it would be preferrable to pass the compilable main file to the script, consider the cascading include infrastructure and do any updates to this one. Which leads me to the second approach:

Using python-ly

python-ly is able to parse a document starting from its main file and build up the whole include structure.

One motivation for the reorganization of openLilyLib was making it accessible for being used by tools like Frescobaldi (by providing one single dependency with consistent API instead of arbitrary projects). Therefore it is conceivable to add support for openLilyLib's structure (e.g. the loading mechanism) to python-ly as well. It would then also be able to follow the include structure with \loadModule etc. (I also think of including \includePattern as an openLilyLib core functionality). So it seems a possible approach to implement it within python-ly.

It would then be necessary to determine to what extent we should draw from, reuse or even use convert-ly. An approach could be to implement the actual conversion process as a convert-ly extension as described above, but use python-ly to collect a list of files that needs to be updated.