Live data from Hacker News

GitHub Package Registry

github.com

161–170 of 389 posts

Re: GitHub Package Registry

#161

Earlier quoted context omitted.

Yes, it has a package registry feature for NPM and Maven: Maven: https://docs.gitlab.com/ee/user/project/packages/maven_repos... NPM: https://docs.gitlab.com/ee/user/project/packages/npm_registr...

The NPM support is basically not more than a proof of concept. It cannot be used for anything production-like. https://twitter.com/eatingfoodbrb/status/1101461965036244993

GitLab Product Manager here

Thanks for your feedback on NPM registry support in GitLab. We release minimal viable change (MVC) and then iterate on our product functionality. Here are some of the issues we have related to NPM support:

https://gitlab.com/gitlab-org/gitlab-ee/issues/10024 https://gitlab.com/gitlab-org/gitlab-ee/issues/10050 https://gitlab.com/gitlab-org/gitlab-ee/issues/9164 https://gitlab.com/gitlab-org/gitlab-ee/issues/9104

Re: GitHub Package Registry

#162
post #115

There's something slightly concerning about ceding responsibility for distributing the world's open-source projects from a family of strong independent repositories to a centralized platform owned by a tech giant.

Microsoft is just trying hard to achieve Antitrust(movie) villain goals, Github plus "telemetry" is a pretty good coverage.

Re: GitHub Package Registry

#164

Earlier quoted context omitted.

> Doesn't this bifurcate the namespace of literally every packaging system they are supporting No. Unless you consider the URL the namespace, but it's not. E.g. I can download the deb "vscode" from https://packages.microsoft.com/repos/vscode Or I could download that it from a GitHub-user controlled URL, or someone's random website. The name of the package is still "vscode", regardless of what location it was fetched…

> No. Unless you consider the URL the namespace, but it's not. It is for docker images. `foo/bar` is implicitly `hub.docker.com/foo/bar`.

True.

I think people are pretty well accustomed to that though. Dockerhub, AWS ECR, Google Cloud, etc.

Re: GitHub Package Registry

#165

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.

I don't think developers should place too much trust in any platform vendor. (Apple and Swift, Apple and Metal, Google and AMP, Google and Dart, Amazon and AWS... the list is endless.) Their interests are fundamentally at odds with ours.

Platform vendors benefit when developers are locked in by network effects. Developers maximize their value when their skills are transferable.

And that goes for Github and its package registry. Concentration of power is problematic.

Re: GitHub Package Registry

#166

This is pretty interesting. Github really is becoming the social network that MS never seemed to be able to create. We already use it as our portfolio of work for potential employers. We collaborate with fellow enthusiasts and maybe even make new friends. We host our websites from it. Abuse it to store binaries, too. And now, along side, source code we can use it as a CDN of sorts to serve packages, for free, sounds…

npm could already install from GitHub repos..

Re: GitHub Package Registry

#167
post #158

Everyone, if a programming language you use already has a good package registry (like ruby has rubygems), I would be extremely wary about switching to github. Don't put all your eggs in a large company's basket.

Oddly enough, before gemcutter and the refreshed rubygems.org, GitHub used to serve gems. IMHO, it was the easiest way to publish gems and it had a built-in namespace system where your username was prefixed to the gems (e.g., my Rails fork would be "nirvdrum-rails").

It took a while to clean up the mess when GitHub decided to close down its gem server. Workflows needed to be adapted, dependency lists updated, and so on. I'm certain there are still gems that never made the transition.

GitHub is a different company now than they were a decade ago, so this may be less of a cautionary tale and more of a blip in their history. The JS package management space is interesting in that its primarily hosted by a private company, in contrast to Ruby's being funded by a non-profit. Betting on GitHub still running its package server in a decade may very well be safer than betting on NPM still being around.

Re: GitHub Package Registry

#168

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…

There have been a few decentralized GitHub projects, but they've been largely ignored by developers. For example gittorrent or axic/mango or gitchain.

When I have tried to promote them I've been downvoted. It seems pretty strange to me.

Re: GitHub Package Registry

#169
post #129
post #115

There's something slightly concerning about ceding responsibility for distributing the world's open-source projects from a family of strong independent repositories to a centralized platform owned by a tech giant.

Hopefully something along these lines will also be added to Gitab. I share your concerns, but I've also long had the feeling that both NPM and Maven are a security disaster in the making. Having the dependencies being published from the same place that stores the actual code, gives me a little hope that things will improve from the security and design perspective.

...by adding a single point of failure?

Re: GitHub Package Registry

#170
post #93

Earlier quoted context omitted.

Pure speculation, it would not surprise me to wake up someday and see MS has bought Stackoverflow. Given their direction of integrating the entire developer experience, it would make sense. MS is upgrading technical docs across the board, organizing and linking to SO content would make sense.

In light of StackOverflow looking for a new CEO, layoffs in the past year and a half, $68 million in venture capital looking for a return, and Joel Spolsky's connections to Microsoft, this might actually happen. I've also gotten the impression that StackOverflow's recruiting product isn't doing so well. It seems to be a few hundred dollars a month for a single job posting, but the results for recruiters are apparentl…

StackOverflow for Teams seems like a really hard sell too. $5-10/user/mo is pretty steep, especially for a service that needs a significant-size userbase to "work".
Post reply on HN