[matharmin]

In my experience, using git as a dependency source for NPM (including yarn) or Ruby never worked well. It works for a simple case, but it's usually much slower, has issues around managing credentials for private repos, and doesn't have a nice way to publish built files.

[bad_user]

Also, most importantly, Git repositories are not immutable and any package repo that's not immutable is a terrible, terrible idea

[rkeene2]

This is one reason I created hashcache [0][1], for referencing remote immutable resources that can be addressed by their cryptographic hash. I used this in my Linux distribution to download source tarballs for every package by their SHA2-256.

[0] https://chiselapp.com/user/rkeene/repository/hashcache/ [1] http://hashcache.rkeene.org/

[ageofwant]

git repos can be as immutable as you want. you just need to point your package manager to a commit or tag, instead of a branch head. if you are worried about a rebase, well you have that issue with any public artefact stores.

[bad_user]

The point is that it's not your Git repo, usually, when talking of dependencies, so it's not really about what you want.

SHAs can't be changed, but they can be deleted. And on GitHub, entire projects, usernames, orgs can be deleted. Or renamed. In case of a user rename, GitHub does maintain redirects for awhile. Until that username is taken by somebody else.

[ageofwant]

If that is a big concern you can fork. If you are building production systems with dependencies on eggs you can't find in pypi you probably should take control of those in your own copies. I can't recall once that I had to do that for things that I ask money for though... if its not in pypi its probably not worth using. And if it is useful, forking or just copying the module or package into your own code base takes care of any shifting dependencies.

So yea, does not seem to be a problem that actually exists.

[bad_user]

> If that is a big concern you can fork

Surely you must be joking.

Yes it is a big concern and the solution is to use repositories that aren't so volatile.

[juliusmusseau]

Copyright law prevents package repos from being truly immutable.

Fortunately a copyright takedown request is not a typical scenario, but it does happen, even with "immutable" repositories like maven-central.

[bad_user]

Once a piece of software is released as open source, it can be freely distributed. And Maven Central packages require an open source license. The author might own the copyright, but he licensed that copyright away when publishing on Maven Central.

In other words a "copyright takedown request" isn't valid, unless the author was in violation of the copyright of somebody else while publishing those packages and this was decided in a court of law.

It might happen, but I have never heard of Maven Central packages being removed.

But I do see GitHub repos being renamed or removed all the time and I have seen NPM packages removed, for no reason other than the author wanted so, screwing the entire JavaScript ecosystem.

[lmm]

> In other words a "copyright takedown request" isn't valid, unless the author was in violation of the copyright of somebody else while publishing those packages and this was decided in a court of law.

The DMCA process is law. Maven Central (like anyone else who hosts things) have to respond to valid takedown requests (which means taking down content long before any court case; even if a counter-notice is filed the content still has to be taken down temporarily) or else they'd become liable for infringement themselves. It's less common than on github or NPM, sure (which I suspect has more to do with the complexity of maven central's registration process than anything else), but it happens and any host on the scale of maven central needs a process in place for doing it.

[juliusmusseau]

Even bad_user's assertion that "Once a piece of software is [legitimately] released as open source, it can be freely distributed" is not 100% true. There is a mechanism in US copyright law through which copyright holders and their heirs can unilaterally retract copyright grants and licenses 56 years after the initial grant or license.

Granted this is quite the esoteric edge case... at least for now. ;-)

[aianus]

At least for Ruby, it was easy to pin a specific commit SHA in the Gemfile to guarantee immutability.

[koolba]

That does not guarantee it exists at the source repo though. You can’t create different content at that same hash, but you can rewrite history or delete the branch of that hash entirely and it will eventually be GCed away.