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
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user

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

Reply via email to