Re: openLilyLib

[Urs Liska]

Hi Joram,

Am 08.11.2016 um 22:22 schrieb Noeck:

Hi Urs,

I liked the idea of oll from the start and I used it quite often after
you published functions used in the Fried songs publication.
I liked because:
- the nice functions (mostly around the Fried project)
- it's a place where code can go more quickly than into lilypond proper
- the edition engraver is great
- it's like the LSR but, updateable (git pull) and includable (no
  copy&paste)

But then I never understood how oll is supposed to work after the
restructuring and the restructuring is going on for much too long. So I
decoupled from the remote version and just kept what I had.

This is actually an extremely sad situation that I'm very worried about. I can't blame anyone but myself for it (but I don't feel inclined to actually blaming me), but it's just too big and complex a task for me to squeeze in between all the other things. If there were some people (or actually at least one) to join this would probably have long been completed by now. I know from experience that my projects always went forward when someone joined, usually for some specific reason.

I have about six tools I use regularly which I have in a branch of my
local copy of oll and I already wanted to contribute them (if they are
helpful, a few are perhaps too trivial). But the current state is too
confusing for me.

I just respond to your mail, other than that I consider my contribution
and possible future contribution too small to be relevant or to be
demanding.

Some more comments inline:

1)
A "snippets" library located at https://github.com/openlilylib/snippets.

That's the part, I know and like. If I use it for a score and want to
have it standalone, I can just copy a function I need to avoid the
dependency. \include is easy to understand and use.

2)
A library infrastructure. Below https://github.com/openlilylib/ there is
a number of repositories circling around the oll-core package.

I don't understand the point of such an endeavor, yet.

I felt the need for a way to get things more organized and coherent. As it is the "snippets" is just a heap of random functionality, and it turned out that the directory structure is way too weak as an organizing factor.

What I wanted was a) a way to collect coherent functionalilty into named "packages" and b) a way to have maintainers be responsible for individual packages. It's not the intention to replace the snippets with that, though.

The first step was to create these packages *inside* the "snippets" repository, within a subdirectory /ly. While this technically worked out pretty well there are two major downsides to the approach:
1) it felt arbitrary that you need to add *two* directories to the include path
2) there was no way of structuring responsibilities on a Git/Github/team level.

This was the motivation to go one step further and pull the packages out to be independent repositories, which is similar to what other languages' package repositories (PyPi, npm, etc.) do.

Now there's a package oll-core at the center of things, providing common base functionality. When you include that you automatically have access to quite a number of tools, for example

• a file/path handling module similar to Python's os.path module
• powerful option handling (that can also used to store data (e.g. music expressions)
• a logging mechanism
• and some more

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.

Unfortunately 2) is still a work in progress or rather a construction
site 

That's the problem. I remember that I once wanted to use a script and I
found 3 instances in different places and on different branches. One
more outdated than the other. It is a chicken-and-egg problem.

Eventually everything should of course be in one place only. When code from the snippets repo is implemented in a package the respective function should be deprecated and at some point removed from snippets. And all of the stuff inside snippets/ly should be removed as soon as it is re-implemented in standalone packages.

I won't be available for a GSoC project, but in general a library could
be built from small contributions if the infrastructure (module
mechanism) was working and if the general structure was defined.

Well, the infrastructure *is* working, and I have successfully used it to build upon the included functionality, which was an amazing experience.
The big problem is that it's not *documented*. 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.

lyp, oll. What other repositories do you think of?

None, actually.

Urs

Best,
Joram

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user