Re: ScholarLY - introduction and call for collaboration

[Urs Liska]

Hi Samuel,

thanks for your thoughts. They are not offending at all but express 
valid concerns.
However, I think there are good reasons to go the way I (and others) are 
going.

All these things have to be seen in the context of an idea/project you 
can't know yet - "specifications" for a common library infrastructure.

Libraries are a good way to extend LilyPond without having to add 
functionality to LilyPond itself. And I think everybody who reaches a 
certain productivity level will have his/her own library or libraries of 
some sort. Basically openLilyLib emerged from the wish to make such a 
personal library publicly available.
However, by now openlilylib is a rather unstructured mass of code and 
not much more than an arbitrary _collection_ of snippets. The main 
difference to the official LSR is that openlilylib is _includable_ while 
you have to _copy_ snippets from the LSR and integrate it with your own 
files. In a way this is good because it is suitable for its original 
idea, namely to be a place where interesting code can be stored and made 
available. But it's already quite unwieldy to see what is actually in 
there, and this will definitely not become better when it grows more.

So the idea is to reach a state where it is possible to create libraries 
in a consistent way and where it is very easy to "install" such 
libraries to make it available from LilyPond documents. This will make 
it possible to create libraries with specific "missions" (as you call 
it), for example scholarly editing, but also contemporary or ancient 
notation or whatever.
In a way this should be similar to packages/modules for programming 
languages or a LaTeX distribution. There you will know (or get directed 
to) that when you are looking for functionality X you should have a look 
at module/package Y. This may also encourage people to contribute their 
tools to a given library instead of only setting up their private toolkits.

One crucial part of that idea is creating a system of auto-generating 
documentation from the code files, also similar to how programming 
languages do it. Such a system will make the documentation and use of 
libraries much more convenient.

One more idea is to also develop a kind of "package manager" that would 
make it easy to get selected packages. But this is not thought through 
at all yet.
A compromise (which might actually be the perfect solution) could be to 
create one "meta" repository that _contains_ arbitrary libraries. That 
way one would only have to download/clone one repository and could 
access different libraries using some kind of namespace, e.g.

\include "oll/some/function.ily"
\include "scholarly/annotate.ily"

I can see that all this activity still looks kind of scattered but the 
idea is to have a quite consistent and coherent environment in the 
not-to-distant future.

Best
Urs

Am 28.01.2015 um 00:18 schrieb tyronicus:
> I am all in favor of the collaboration, but I wonder if I might
> pessimistically ask why we use so many discrete projects and repositories.
>
> It seems to me that we could accomplish much more by using one git project
> instead of having openlilylib, the LSR, and our newest projects, ScholarLY
> and GASP. On top of all these projects, I've noticed that a few LP users
> have their own repos of snippets and tools.
>
> Wouldn't the beginning to intermediate user of LilyPond be benefited by the
> ability to find all of these resources under one roof? Even the advanced
> user might more willingly contribute to the various projects if they were
> all right there in front of him/her.
>
> Assuming it is an idea of the different projects having separate 'missions,'
> why not broaden our horizons?
>
> I hope I haven't angered anyone who fills differently than I do. These are
> just the thoughts of an admitted beginner.
>
>
>
> --
> View this message in context: 
> http://lilypond.1069038.n5.nabble.com/ScholarLY-introduction-and-call-for-collaboration-tp171140p171149.html
> Sent from the User mailing list archive at Nabble.com.
>
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user