Re: openlilylib pull request
Le 09/05/2022 à 01:59, David Kastrup a écrit : Simon Albrecht writes: On 08/05/2022 20:37, Jean Abou Samra wrote: The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. In many cases, that may be true. In other cases, it really makes sense to allow for a more flexible space of user code available to the community. The TeX ecosystem may have some issues with maintaining packages and especially with interoperability, but it provides an unbelievable wealth of high-quality additions to the core software that could never be provided otherwise. Due to the relative lack of adoption and the small size of the community LilyPond can’t seem to take some threshold toward creating a similarly stable ecosystem (so far?). The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. I am not sure I would say that. Even though LaTeX is already more workable than plain TeX, it quickly gets pretty limited in features on its own, and programming it is very much not fun at all if not atrocious. So you need packages to accomplish about any standard task. The very quality of core LilyPond may be the reason why packaging layers around it have failed to really take off and LSR remains far more commonly used than openLilyLib. Not to mention that many amazing LilyPond snippets are expressed in less than 50 lines of Scheme code, which is just as convenient to inline in your file than to include. I don't think the same holds with TeX. We need to reflect on what packaging systems bring to other projects and what in that is or is not relevant to the LilyPond community. In other words, we should create a packaging system that fits a purpose. I don't believe that a packaging layer will enable us to steal some of LaTeX's success by its only existence. Another aspect is that TeX is frozen, and working with it is working with a prehistoric and pitiful piece of software by today's standards. But it's impossible to change due to backwards compatibility (I think), so you get more and more new competitors, each with its own incompatibilities: XeTeX, LuaTeX, ConTeXt. Having most features baked into LilyPond's core means we can make it evolve rather fast compared to the size of the project. convert-ly also helps there. Jean
Re: openlilylib pull request
Am 09.05.22 um 01:59 schrieb David Kastrup: The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. This might get off topic quickly, but I don’t want to let that uncommented WRT ConTeXt: ConTeXt is driven by a small community, even if Hans Hagen still does most of the programming (in communication with experts, e.g. for math or “exotic” languages). His company doesn’t play a big role and could hardly ever use ConTeXt for commercial projects (not because you couldn’t use ConTeXt for commercial projects, I do, but because the projects they got paid for didn’t involve producing PDFs). ConTeXt is monolithic insofar as it usually doesn’t need some settings as a package, because you just setup the settings yourself, and the interface is quite consistent. There *is* a growing number of modules, though. Many are part of the distribution, others are “third party”; if they gain wider acceptance, they often get integrated into the distribution, like the bibliography module. It’s common for ConTeXt users to just install all available modules – but LaTeX users also often just install the whole TeX live distribution. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. I guess development of open source projects depends the most on people who do it against all odds (like you). Of course it helps if they do it in a way that others can chime in. And then we need people who help building the community, answer questions etc. Hraban
Re: openlilylib pull request
Simon Albrecht writes: > On 08/05/2022 20:37, Jean Abou Samra wrote: >> The case study of how OLL fell out of maintenance is one of the >> things leading me to think that a model where snippets providing >> significant functionality and becoming somewhat popular get >> upstreamed into the LilyPond core is a better fit for LilyPond >> than them letting them be provided through external packages. > > > In many cases, that may be true. In other cases, it really makes sense > to allow for a more flexible space of user code available to the > community. > > The TeX ecosystem may have some issues with maintaining packages and > especially with interoperability, but it provides an unbelievable > wealth of high-quality additions to the core software that could never > be provided otherwise. Due to the relative lack of adoption and the > small size of the community LilyPond can’t seem to take some threshold > toward creating a similarly stable ecosystem (so far?). The "TeX ecosystem" consists of plain TeX with fudge-ons (comparable to LilyPond and LSR snippets), of the monolithic Context (driven by a not-much-more-than-one-man company), and of the modular LaTeX. The only system that has exploded in number and functionality of extensions and styles is LaTeX. That suggests that the development potential is not as much dependent on the underlying technology but of readily available interfaces for integrating both functionality as well as document styles into a fixed framework. -- David Kastrup
Re: openlilylib pull request
On 08/05/2022 20:37, Jean Abou Samra wrote: The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. In many cases, that may be true. In other cases, it really makes sense to allow for a more flexible space of user code available to the community. The TeX ecosystem may have some issues with maintaining packages and especially with interoperability, but it provides an unbelievable wealth of high-quality additions to the core software that could never be provided otherwise. Due to the relative lack of adoption and the small size of the community LilyPond can’t seem to take some threshold toward creating a similarly stable ecosystem (so far?). Best, Simon
Re: openlilylib pull request
Le 08/05/2022 à 20:37, Jean Abou Samra a écrit : Le 08/05/2022 à 20:08, Simon Albrecht a écrit : Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? I don't think so. Urs left the community, as you know (and for reasons unknown to me). I haven't seen anyone really maintaining OLL recently. Andrew (in CC) had set up http://openlilylib.space/ and a migration to GitLab at some point, but the website has been down for a while, and I can't find the repo on GitLab. If I recall correctly, the main people involved in coding OLL apart from Urs and Andrew were Janek and Jan-Peter. Both of them are inactive at the moment. Did I miss anyone? (The activity period of OLL was before I started getting involved.) I may be wrong, but I guess the most straightforward path for you right now is to fork this repository and advertise the fork. The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. PS: I wrote this before actually looking at the PR, and coincidentally it turns out that it removes code for a functionality that I integrated into the core :-) (Although I wasn't even aware that it existed in OLL at the time, and just implemented it following a 10-year-old issue in the tracker, opened by Urs.) Best, Jean
Re: openlilylib pull request
Le 08/05/2022 à 20:08, Simon Albrecht a écrit : Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? I don't think so. Urs left the community, as you know (and for reasons unknown to me). I haven't seen anyone really maintaining OLL recently. Andrew (in CC) had set up http://openlilylib.space/ and a migration to GitLab at some point, but the website has been down for a while, and I can't find the repo on GitLab. If I recall correctly, the main people involved in coding OLL apart from Urs and Andrew were Janek and Jan-Peter. Both of them are inactive at the moment. Did I miss anyone? (The activity period of OLL was before I started getting involved.) I may be wrong, but I guess the most straightforward path for you right now is to fork this repository and advertise the fork. The case study of how OLL fell out of maintenance is one of the things leading me to think that a model where snippets providing significant functionality and becoming somewhat popular get upstreamed into the LilyPond core is a better fit for LilyPond than them letting them be provided through external packages. Jean
openlilylib pull request
Dear community, I have made some small updates to keep the openlilylib/bezier module working with current versions of LilyPond and created a pull request on GitHub. Is anyone currently able to notice and approve the request? Best, Simon
