lilypond-user
[Top][All Lists]
Advanced

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

Re: openLilyLib


From: Noeck
Subject: Re: openLilyLib
Date: Thu, 17 Nov 2016 00:02:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Dear Urs,

it was not my intention to blame you. I know you put a lot of effort in
it. I just wanted to mention what makes me keeping some distance to oll
at the moment in order to solve some of it. While I am not the right
person to boost this, I would like to take this reminder and look at
openlilylib now again.

Therefore, I'd like to ask for some direction - publicly because others
might profit from the explanation:


1. What are the repos on github I should look at?
   https://github.com/openlilylib
   I mean which ones are deprecated and what is it you want to develop
   and bring in a good shape? On github all repos are equally listed.
   Only openlilylib says 'deprecated' in the description.
   Could there be a prefix in the description telling the newbie which
   of the repos are packages for the oll-core system?
   lily-fonts and oll-latex probably not.
   What do I need to checkout? oll-core, snippets?
   scholarly, edition-engraver are packages?


2. As mentioned already: Why so many places for the same content?

   - snippets and openlilylib (ok there is a deprecation warning on the
     latter, won't count that)
   - edition-engraver snippets/editorial-tools
   - lily-fonts / snippets/fonts / snippets/py and different branches
   - a lot of duplication inside snippets (ok, you said everything there
     is kind of deprecated)

   There should be one place for every part only, all others should
   have deprecation warnings. Rather than copying everything and have
   multiple places while working on the new system, I would recommend
   to have a separate branch, where things are in the new location only
   and a stable branch where things are where they used to be, but never
   twice on either branch.


3. Specificly for snippets: Which branch should I checkout and how is
   it supposed to be used now? Only the ly folder or together with the
   oll-core repo?

You see I am a bit lost. OpenLilyLib (now snippets) used to be easier to
understand, I just include it and use what is in there. I will try the
advice from your previous mail.

> It's not the intention to replace the snippets with that, though.

What is snippets intended for if all the other packages exist?

> The first step was to create these packages *inside* the "snippets"
> repository, within a subdirectory /ly. 

So do I want to use snippets still?

> Other packages (like scholarLY or the edition-engraver) can be either
> loaded thorugh oll-core's module handling or \include-d directly (upon
> which they'll implicitly load oll-core). You now only need to add one
> directory to the include path.

And which path? oll-core?
I'll test that. I have to say that I liked the one repo, because now I
have to update several repos.
Where are these repos to be installed, all in one directory?

> And as there still isn't
> that cool mechanism to generate package documentation from doc comments
> in the files I'm kind of reluctant to add more packages.

I was very fond of docstrings etc. some years ago, but I actually like
readme.md files (or similar) much better now than cluttering code with
insane amounts of comments like the doc creation in latex does. User
documentation and making code understandable for developers is something
different IMHO.


Something totally different in the end: I wish these packages are not
needed for too long, because I would like to see the good parts of it go
into lilypond proper at some point. One of the biggest drawbacks of
LaTeX is IMHO the many inconsistent packages. And when sharing .ly files
I don't like if others are required to install a whole bunch of extra
packages via git which they might not know. For Mutopia scores it is
also a no-go. So I see the packages as a test-bed and temporary stage.

Thanks for your advice! I hope my mail is not too long.
Joram


PS: Some kind of answer to this mail would be an overview-documentation
about oll-core and the corresponding packages. I would be happy to
review such a (even small) documentation. I feel not able to write it :)



reply via email to

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