Hi,
Le 16/05/2020 à 20:02, David Kastrup a écrit :
Valentin Villenave <[email protected]> writes:
On 5/16/20, Werner LEMBERG <[email protected]> wrote:
IMHO only bugfixes should be applied to `musicxml2ly` since `xml2ly`
covers much more of MusixXML (and will, AFAIK, also eventually support
its successor, MNX).
Huh. xml2ly has very different requirements than musicxml2ly and is
(AFAICS) unlikely to ever be integrated into LilyPond. Anecdotally, I
have encountered several cases where musicxml2ly turned to provide
much more useful output than xml2ly (but that was a couple of years
ago, maybe its development has sped up since then).
Plus, since we’re discussing python-based tools, there are a few
useful functions being developed in python-ly (as part of
Frescobaldi), which share a bit more DNA with musicxml2ly than with
anything else. So I wouldn’t count musicxml2ly out just yet.
Personally, I see nothing wrong with maintaining tools while they are
used and distributed. In a corporate setting, alloting large amounts of
resources into a part of the tool set that has a perspective to be
replaced in the course of a corporate development makes of course little
sense.
We aren't there. We have no timetable for a replacement or its
viability, and so I don't see the point in discouraging contributors
from making fixes to what will continue for an indeterminate time to be
part of the tool set useful for achieving objectives.
Thank you all for your replies. Based on that information, I decide to
dive into the code, and we'll see what I can improve in it. My concern
was about the possible replacement being planned and pending (I told
myself it could have been delayed by the transition to GitLab), but if
it is still to be discussed wether a replacement is tangible, then I
will step into musicxml2ly with the rest. I'm unlikely to implement
stunning features anyway. My goal is rather to adapt it to Python 3, and
thus make it more maintainable by simplifying many parts of the code
that can be rewritten elegantly using constructs and standard modules
appeared in later versions of Python. Also, I consider it an investment
for a future when I would be done with the very exacting part of my
curriculum I'm currently in, and depending on many factors, I might
start contributing more seriously (but that's not for right now, really).
Best,
Jean Abou Samra
