Live data from Hacker News

GitHub Package Registry

github.com

231–240 of 389 posts

Re: GitHub Package Registry

#231

Doesn't this bifurcate the namespace of literally every packaging system they are supporting, or are they requiring `@author/`-namespaced package names? In the livestream he pokes around a github repo, sees it's one author, and decides that what makes it trustworthy? No GPG signing? The new Actions support (about 50 minutes into the live stream) for auto-publishing from master is pretty sweet. From the very cursory d…

Namespaces in general are a mess. I want domain validated namespaces; github.com/example.com/, docker.io/example.com/, @example.com/, facebook.com/example.com, twitter.com/example.com, etc.. Whoever owns the domain owns the validated namespace. I doubt it'll ever happen though since (IMO) namespace squatting makes services look more popular than they are and some sites (ex: GitLab) already allow usernames with dots in them.

As for registries, I didn't like Docker's URLs when I first started, but now I'm convinced it's a good scheme. I can "own" my (domain) namespace by running my own registry. The implementation could have been a bit better though:

* The daemon should allow the user to force the use of a local mirror / cache as a registry. * The daemon should pass full URLs to the registry for requests (https://github.com/docker/distribution/issues/1620).

That way something like Sonatype Nexus could be used as a local caching proxy for all Docker images and could automatically request images from (public) upstream repositories without any additional config.

The new TLDs make perfect identities / namespaces and there are plenty to go around.

Re: GitHub Package Registry

#232

While the technical side of the news is interesting, the organisational repercussions worry me. Microsoft (who owns GitHub) is already one of the largest tech companies, and I would not be surprised if this move was intended to weaken NPM and Docker in an attempt to acquire them. I fear a future where everything one requires to develop "socially" depends on a single super-entity. GitHub and VSCode were the first step…

That would make sense as a worst case scenario but I'm not sure the evidence suggests that's the route they're going. If they wanted to acquire a CI/CD product, they would've bought Travis when it was being shopped around for a buyout.

But they already have CI. See azure pipelines.

Re: GitHub Package Registry

#233
post #185

I'm worried about the resiliency of code distribution as we continue the trend of centralizing distribution in a few large companies. GitHub has had service outages in the past, so what happens when not just our repositories but also now packages are not accessible the next time that happens? It would be great if they'd implement it using an open/decentralized protocol such as IPFS, so that even if GitHub went down t…

The problem is that hosting and bandwidth aren’t free and abuse is a big problem. Managing a distributed petabyte-scale archive which gets updated so frequently is a significant engineering problem even for a single party — now consider how you’d handle redundancy and routing when you can’t rely on any of the parties involved, and you have enough different objects being accessed to turn away most participants unless…

Thanks for your insight. I think those are definitely real challenges to a fully decentralized system, but allowing some sort of federation can't hurt. The worst case scenario would be if GitHub is the only one pinning all the packages, which is what we would have now. It'd be nice to at least have the option to mirror in a way that interops with an open protocol so it would still work if GitHub went down. I doubt many mirrors would pin the entirety like GitHub, but I know I would certainly be happy to mirror my own and any open source software I've used.

Re: GitHub Package Registry

#234

Is centralization of open source a good thing for the world or not? This thread seems to be overwhelmingly positive. And in the end we all will be critisizing it if all package repositories will be handled by a single entity. And that entity that is being applauded here in this case happens to be the most valuable corporation in the world right now. Healthy skepticism seems to be a disappearing attribute in the tech…

As usual it will take a disaster for people to realise it was a bad idea. Microsoft tried to destroy Linux in the past. Literally. Linux is what gave us git in the first place, and docker, and so much technology that we love today. Oh how quickly the past is forgotten when convenience is on the table.

Re: GitHub Package Registry

#235
post #53
post #31

This is really outstanding. It will mean the death of Maven Central, about which I have mixed feelings. On the one hand, Sonatype deserves enormous thanks for what they have done for the open source world, as does mvnrepository.org. Their central repository has been free and maintained for a long time. Thank you, Sonatype. On the other hand, it took me three days to release a new version of one of my artifacts the ot…

Hey Microsoft, if you're listening, you should throw Sonatype or other Maven-related organizations a few bucks. They deserve it.

This actually sounds like a surprisingly not bad idea

Re: GitHub Package Registry

#237
post #127

Earlier quoted context omitted.

Yes, but that's not a new concern - to some, GitHub has always represented an anathema to what git was supposed to be and bring. Centralization at a proprietary vendor, instead of open systems interacting. Then locking people in further by network effect and adding centralized products around git. That it's become so popular many people equate GitHub with git adds insult to injury. I completely understand why this al…

I have the opposite view: the success of GitHub and the growth of code being open by default with everything running through git has probably brought more people into the git ecosystem than would have otherwise. I primarily use GitHub, but whenever I need something that I need to run myself I know I can fairly seamlessly switch over to something like GitLab. For example, if GitHub ever started using a very proprietar…

I don't believe you would. It's more probable that you'd install that proprietary application to get the features which standard git lacks at that time.

Re: GitHub Package Registry

#238

Earlier quoted context omitted.

> MS's core competency has always been developers. As a developer who still has to work very hard to forgive MS for all the pain IE6 put me through a decade ago, this grates on my ears, even though I understand that it might be true in the abstract. Classically, MS has been good to developers who agree to be chained to their platform, but has made life extremely difficult for developers who want or need to be platfor…

A lot has happened since IE6.. I think it might be time to move on. Eg their main focus for .net Core has been multi platform - ie the last 3-4 years! Visual Studio Code. And on browsers they are building what will probably be a better Chromium than Google's Chrome, in the new Edge.

All Trojan horses.

Re: GitHub Package Registry

#239

Looks like Docker, node/npm, ruby/gems, java/maven, and nuget... but no Python? Seems an odd choice for the one to leave out.

people may be reading too much into this. notice there is no go either? maybe because we often tend to pip install and go get directly from github repos and releases? so whether they are working on proper integration or not, nothing is being missed here.

Re: GitHub Package Registry

#240
Watch out Nexus and Artifactory, I've been commenting about this for a long time (on reddit). With the advent of Bitbucket Pipelines, GitLab CI and finally GitHub actions, I knew it was only a matter of time before package management was added as well.

This is fantastic, I love the idea of one stop shopping for source control, CI/CD and a package registry.

Post reply on HN