RE: lyp - a Package Manager for Lilypond

[Sharon Rosner]

> 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.