lilypond-user
[Top][All Lists]
Advanced

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

Re: lyp - a Package Manager for Lilypond


From: Urs Liska
Subject: Re: lyp - a Package Manager for Lilypond
Date: Fri, 29 Jan 2016 15:08:42 +0100
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Am 29.01.2016 um 14:43 schrieb address@hidden:
> On Fri, 29 Jan 2016, Sharon Rosner wrote:
>>> ...as hosted Git repositories.  I thought that was a dealbreaker, but I
>>> tried to give it a fair chance.
>>
>> Please explain why packages as hosted git repositories is a bad idea. What
>> would be a better solution in your opinion?
> 
> Version control systems in general are not well-suited for distribution of
> software to users.  They significantly increase the level of skill and of
> previously-installed software a user needs just to get in the door.  It's
> not a good idea to require a client for a much more complicated protocol
> just to serve the function adequately addressed by HTTP or FTP.  Git in
> particular is an especially poor substitute for HTTP (as compared to other
> version control systems) because when used as directed, it requires
> transferring the entire previous history of development to anyone who
> just wants a copy of the current version, and those people will
> disproportionately be the ones least able to make use of the history.

I can't comment in detail, but the idea behind Sharon's approach is that
such Git based packages *do* contain a history that's useful for
everybody, namely all *versions* of the package.
lyp will fetch the repository and can then checkout arbitrary versions
(that it may need for the dependency resolution Sharon is writing
about). LilyPond itself won't load the packages from the repository but
from the checked out directories for individual versions.

With regard to everything else I think nothing speaks against
*extending* lyp to support arbitrary directories as well. The Git
approach isn't absolutely crucial to lyp's internal working (IIUC) but
is the foundation for a number of its features. I'm sure there will be a
suitable way to support other types of packages, with less features.

Urs

> Further comments are here:
>    http://ansuz.sooke.bc.ca/entry/230
> 
> That article discusses individual software packages using Git for
> distribution.  Building a package manager tied to Git, so that ALL
> software it can install must use Git for distribution, compounds the
> issues by unnecessarily imposing them on all developers.  Everybody's
> required to have public Git repositories, which is a much higher bar than
> requiring developers to be able to put files on HTTP servers, an approach
> which has served the community well for many years (as did anonymous FTP
> before that).  It's not clear what benefit Git provides over much simpler
> ways of distributing files; but it has some real disadvantages.
> 
> When distributing software requires Git, there's an implicit encouragement
> to use Git for the actual development too, and that unnecessarily limits
> the tools and organizational structures anyeone can use when building
> software that will be installed by this package manager.  Git may be
> appropriate for some projects; but a built-in assumption that Git is
> appropriate for every project, even in the limited space of LilyPond
> development, is harder to justify.
> 
> "A public Git repository" is in practice almost the same thing as "a
> public repository on Github," and Github in particular has had some recent
> issues with both technical reliability and human governance.  They had a
> big outage yesterday.  It's not good to put all the community's eggs in
> the Github basket.  Requiring everyone who wants to build a package to
> build it in a Git repository does not require them to build it on Github,
> but does make it a little harder to build elsewhere.
> 


-- 
Urs Liska
www.openlilylib.org



reply via email to

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