lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Updating library code


From: Urs Liska
Subject: Updating library code
Date: Fri, 23 Oct 2015 12:43:04 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

>From an openLilyLib perspective I have a question for all of you who
maintain their personal LilyPond code libraries: How are you dealing
with keeping code working and consistent?

What I mean is:
Syntax changes in LilyPond can be handled (mostly) with convert-ly. But
what happens when
a) a LilyPond update changes the behaviour of a library function e.g. by
making it obsolete or by "shadowing" its name. When re-touching our
Fried songs repo I ran into numerous errors that seemed strange
initially. But in fact it was quite clear: a number of functions we
developed in that project (or integrated when developed by others on
this list) have later been incorporated into LilyPond. But while the
name of the function usually remained the same the implementation and
interface often changed during the process of integration. The result
was that our main code didn't work anymore because there *was* a
function available of the same name (now from LilyPond) but with a
different interface. In effect it was the funny situation that the
majority of compilation issues could be solved by simply *removing* code
from our library because it wasn't necessary anymore.

While this is basically a very good thing to notice it raises the
question of code consistency. Even when your functions don't go into
LilyPond later you may have or want to change them at any point,
presumably leaving your LilyPond files that depend on that library in a
non-compiling state. It can be quite frustrating having to update all
your existing scores afterwards, especially as that will fall back onto
you rather often - until you have eventually revisited all of your scores.

We have a similar problem with openLilyLib, and as this is explicitly
intended as a *usable* and public infrastructure this really is a
problem. As long as you provide a "snippet repository" it is fair to
assume that a user can tune a snippet when integrating in her own files,
but if it can be accessed through \include there should be a way to
handle the issue.

So in essence what we need is a convert-ly-like tool for openLilyLib,
either as an independent tool or by somehow hooking into convert-ly
itself. Quite some time ago I opened an issue about this and would now
like to get some opinions, ideas and experiences how *you* deal with the
topic.

Please reply here or add to
https://github.com/openlilylib/openlilylib/issues/87.

Best
Urs



reply via email to

[Prev in Thread] Current Thread [Next in Thread]