> 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.
Please note that installing packages using lyp does not require you to manually clone git repositories. In fact, to install packages using you don't even have to install git on your machine. As Urs has already written, having the history available means packages can be versioned by using git tags. > 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. Isn't lilypond using a git repository? You're not suggesting we go back to HTTP/FTP for developing lilypond? > 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 There are websites offering free git hosting, just like there are web sites offering free web hosting. If you're not inclined to use github et al, you can roll your own ala gitlab, but how is that any harder than rolling your own apache/nginx server? > 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. Yes, publishing packages for lyp requires using git for development too, but lyp also supports installing packages from local files (more on that in a separate msg). Please explain how does using git limit "the tools and organizational structures" one can use? > "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. Yes, there's not much competition in the git hosting space, and github is the clear dominator, but people looking for alternatives will find them. Every website will have outages. If I'm not mistaken lilypond.org also goes down every once in a while. > It's not clear what benefit Git provides over much simpler > ways of distributing files; but it has some real disadvantages. ... and ... > but a built-in assumption that Git is > appropriate for every project, even in the limited space of LilyPond > development, is harder to justify. You din't reply to my question regarding an alternative to git, and perhaps I should have gone into more detail as to why using git for distribution was chosen. Urs, Matteo and me finally settled on this solution because it solves a lot of problems related to package management. When you design a packaging system, you need to answer (at least) the following questions: - Where are packages stored? - How are packages versioned? - How are packages referenced? - How are packages published? So we discussed a few alternatives: 1. Piggyback on top of an existing packaging system, like Rubygems or npm.js. Which is not necessarily a bad idea, but can add a certain level of complexity. 2. Write a package hosting website from scratch, with the ability to upload/download packages, a package registry, user management, and of course find a machine to run it on. 3. Git-based package distribution - which solves hosting (on any git hosting site or on your own machine), publishing and package references (any git URL), and versioning (using git tags). Considering the alternatives I think this solution we came up with is clearly the winner. If you can think of a better one please let me know. Sharon Rosner -- View this message in context: http://lilypond.1069038.n5.nabble.com/lyp-a-Package-Manager-for-Lilypond-tp186597p186622.html Sent from the User mailing list archive at Nabble.com. _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
