GitHub Package Registry

Blog post at <a href="https:&#x2F;&#x2F;github.blog&#x2F;2019-05-10-introducing-github-package-registry&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.blog&#x2F;2019-05-10-introducing-github-package-re...</a>.

This is really outstanding.<p>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.<p>On the other hand, it took me three days to release a new version of one of my artifacts the other day. The process for doing a Maven deploy is very complex. It took hours to get my private key to work because the key registries were slow. Then the staging server was slow, and kept timing out. Support was responsive, and said they were dealing with a DDOS attack. On top of that, it takes a while for artifacts to show up in the registry even after they have been uploaded. I&#x27;m glad that getting that artifact out wasn&#x27;t an emergency.<p>This new Github service separates the registry from the artifact storage, which is the right way to do it. The registry should be quick to update because it&#x27;s only a pointer. The artifact storage will be under my control. Credentials and security should be easier to deal with. I really hope this works out.

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 pretty great. All they need now is a place to get coding questions answered (a la stackoverflow) and along with Github jobs it could be really compelling.

It&#x27;s a really nice project overall, having a registry that supports many different projects and run by a company that today is good, is always nice.<p>But we been here before. We trusted npm and now they are trying to squeeze out a profit, and it ruins it for the users. I&#x27;m happy to be proven wrong, but every for-profit company that runs a package registry, eventually stagnates, and ends up implementing things that are not for the users, but for their own profits.<p>I think package management, especially for open source, should not be run by for-profit entities. We need to have something similar to public utilities, where the community funds the registry itself, and the community can own it as well, where the only changes allowed, are changes that are good for the users.<p>This is not that. npm and docker are already run by for-profit companies, so this move by GitHub just adds another centralized package registry for those. It&#x27;s not worse, by it&#x27;s not better either. I&#x27;m a bit mad about the RubyGems part though, as RubyGems is a community project, and they are trying to make it not so, making it worse.<p>What I&#x27;m currently working on, is how I think a Open Source Public Utility would look like. I just submitted a Show HN to show it off, you can see the submission here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19885502" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19885502</a> Website is <a href="https:&#x2F;&#x2F;open-registry.dev" rel="nofollow">https:&#x2F;&#x2F;open-registry.dev</a><p>It&#x27;s basically a community funded decentralized package registry, where the community funds it, and is a part of the ownership of the registry, handled via a governance followed by the contributors. All the finances, development and planning is happening in the open, and Open-Registry is committed to never making changes that are for increasing profits, only changes for making the service better for users.<p>Please, if you have some free minutes, check it out and write down some feedback. We might not be the perfect package registry over night, but I&#x27;m hard at work getting as close as possible, without compromising the user value for it.

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

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.<p>I fear a future where everything one requires to develop &quot;socially&quot; depends on a single super-entity. GitHub and VSCode were the first steps in that direction, and now package management. My guess would be for CI&#x2F;CD to be next on their list, with more integration of Azure somehow (potentially under the hood).

I worry about npm now. The huge public registry everyone loves is run off investor&#x27;s money and subsidized by npm&#x27;s private registry product.<p>But npm has recently changed their nice-people-matter CEO to a now-print-money dude, so I suspect investors&#x27; patience has run out.<p>And now GitHub went directly after the one thing that npm is supposed to be making money on.

I&#x27;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&#x27;d implement it using an open&#x2F;decentralized protocol such as IPFS, so that even if GitHub went down the content would still be accessible.

Doesn&#x27;t this bifurcate the namespace of literally every packaging system they are supporting, or are they requiring `@author&#x2F;`-namespaced package names?<p>In the livestream he pokes around a github repo, sees it&#x27;s one author, and decides <i>that</i> what makes it trustworthy? No GPG signing?<p>The new Actions support (about 50 minutes into the live stream) for auto-publishing from master is pretty sweet. From the very cursory demo, it seems very much like Gitlab&#x27;s CI pipelines.

Seems like the Maven registry is susceptible to artifact hijacking.<p>Say I wan&#x27;t to install artifacts from two GitHub users. I would have to add these two Maven repositories:<p><pre><code> - https:&#x2F;&#x2F;maven.pkg.github.com&#x2F;USER1 - https:&#x2F;&#x2F;maven.pkg.github.com&#x2F;USER2 </code></pre> In that case USER1 can publish an artifact with the same groupId&#x2F;artifactId as USER2 and my Maven will happily install it without suspecting anything.<p>Another case - someone deletes their GH account and another user takes it: <a href="https:&#x2F;&#x2F;blog.sonatype.com&#x2F;hijacking-of-a-known-github-id-go-bindata" rel="nofollow">https:&#x2F;&#x2F;blog.sonatype.com&#x2F;hijacking-of-a-known-github-id-go-...</a><p>Docs: <a href="https:&#x2F;&#x2F;help.github.com&#x2F;en&#x2F;articles&#x2F;configuring-maven-for-use-with-github-package-registry" rel="nofollow">https:&#x2F;&#x2F;help.github.com&#x2F;en&#x2F;articles&#x2F;configuring-maven-for-us...</a>

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 world

This could solve the trust issues with npm - you never know, whether the package you&#x27;re installing is really from the source provided on its npm page

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

This is going to be hard to avoid using for teams with a private git repo, especially private mono repos.<p>The ability to provide any one with access to the repo access to the packages created from it removes an often frustrating management step.

Do I want to use Github for this? I kind of like the npm model where they say &quot;don&#x27;t cache it, we guarantee as much capacity as you want to re-download packages&quot;. I use a lot of go modules, and each of our container builds ends up fetching them all. Github rate limits this and you have to either vendor the modules or provide a caching go module proxy (Athens, etc.). Meanwhile, npm just uses Cloudflare which seems happy to serve as many requests as I desire.<p>In general, I find that caching&#x2F;vendoring dependencies is the most sane thing to do, but it&#x27;s not what, say, the Javascript world appears to be doing. Do we want to move towards a service that already rate-limits package fetches when we already have a service that doesn&#x27;t?

This is big. For a while we have needed a simple, intuitive and centralized artifact storage system for the modern age. I’ve been wanting to build something for ages but never made the time.<p>I also think that this will also have the side effect of exposing a lot of people to package&#x2F;build&#x2F;dist tools from other ecosystems, which might help disseminate best practices outside of their walled gardens. Github helped do this with code, helping to put the spotlight on less popular or more cutting-edge languages<p>This is going to solve a lot of problems for a lot of people.

This is super cool, but I worry that we&#x27;ve basically let a proprietary closed-source service be the de-facto standard for open source software. That really hampers my enthusiasm here.

This is going to be a huge hit for things like NPM Enterprise and Artifactory. Especially useful for small&#x2F;medium teams that&#x27;s want to start from the get-go with an easy way to share modules that will scale as they grow.

... looking forward to the Hacker News post in 4 years about how Github has really lost their way and how they&#x27;re now super evil.<p>Remember this when you guys all rush to sign up for their new services because it&#x27;s easier for you now ;)

I&#x27;m disappointed it doesn&#x27;t support Python. There&#x27;s not a lot of options available for private Python package hosting, it would have been good to have another one.

I&#x27;m working on a SaaS service for developers, so I&#x27;ve built some API client libraries using openapi-generator [1] (using my OpenAPI specification.) The hardest part (by far) has been signing up for all of these different package manager services and figuring out how to release the libraries. Java and Maven was particularly difficult.<p>It sounds so nice to be able to release all of my packages on one centralized service. I hope they support PHP and Python soon.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;OpenAPITools&#x2F;openapi-generator</a>

I agree the artifacts should live alongside the code that produced them. But doesn’t Github killing npm, Inc. and Docker, Inc. in one move indicate Github is too powerful and, therefore, a huge liability? We need decentralized solutions, not another monopoly.

Watching the live stream now (<a href="https:&#x2F;&#x2F;live-stream.github.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;live-stream.github.com&#x2F;</a>). Will likely use the Docker support near immediately. Hoping Singularity will be supportable as well.

GitHub is coming after GitLab :D They first started with Boards, then Github Actions and now with this.

debian packages are also supported it seems: <a href="https:&#x2F;&#x2F;github.com&#x2F;git-lfs&#x2F;git-lfs&#x2F;packages&#x2F;5789" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;git-lfs&#x2F;git-lfs&#x2F;packages&#x2F;5789</a> and <a href="https:&#x2F;&#x2F;github.com&#x2F;alteregofun&#x2F;firsty&#x2F;packages&#x2F;2953" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alteregofun&#x2F;firsty&#x2F;packages&#x2F;2953</a><p>found a ruby one: <a href="https:&#x2F;&#x2F;github.com&#x2F;wintron&#x2F;hola&#x2F;packages&#x2F;4057" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wintron&#x2F;hola&#x2F;packages&#x2F;4057</a> (yes! got it working)

It&#x27;s up now<p><a href="https:&#x2F;&#x2F;help.github.com&#x2F;en&#x2F;articles&#x2F;about-github-package-registry" rel="nofollow">https:&#x2F;&#x2F;help.github.com&#x2F;en&#x2F;articles&#x2F;about-github-package-reg...</a><p>Supports NPM, Docker, Maven, Nuget, RubyGems

So what happens when a package on npm depends on a package on Github registry or vice versa?

It&#x27;s always odd to me that PHP is left out of things like this. What do these other package managers have that Composer doesn&#x27;t?

I&#x27;m really loving the way in which Gitlab and Github are looking to diversify their value-add offerings and auxiliary services without sacrificing any existing basic git functionality or UX, and without aggressively directly competing on the same feature set.<p>This makes it less of &quot;gitlab or github?&quot; and allows developers to more easily decide to use just one for each project based on whichever service better focuses on the project&#x27;s primary long-term goals.<p>If you find yourself in a 2-way split market on a core offering, I think this strategy by both parties is net beneficial for everyone rather than trying to directly compete on all the same features and offerings.

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&#x27;t put all your eggs in a large company&#x27;s basket.

Helping decentralize package managers is Protocol Labs&#x27; top priority for IPFS in 2019[1].<p>Seems very prescient now. Hopefully this gets adopted soon enough, while it&#x27;s still easy to batch-export stuff out of registries. I really don&#x27;t want MS owning the most popular editor, git host, &quot;linux desktop&quot;, <i>and</i> universal package manager in the world. Edit: oh, and programming language (typescript is eating javascript.)<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;ipfs&#x2F;package-managers" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ipfs&#x2F;package-managers</a>

Is there a way I could let some CI service like Travis CI to ONLY publish the packages to this GitHub Package Registry? ONLY means I don&#x27;t want to expose the entire GitHub account to Travis CI but allow only publishing to the registry. So if the GitHub key&#x2F;access-token leaks somehow the possible damage would be limited by registry publishing scope. So something like scoped access tokens.

How did this get to the front page with a dead link?

Watch out Nexus and Artifactory, I&#x27;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.<p>This is fantastic, I love the idea of one stop shopping for source control, CI&#x2F;CD and a package registry.

Link doesn&#x27;t go anywhere?

This will be very neat just as GitHub user experience is so far. Centralization is a questionable, but it looks like that the community values much more the convenience than decentralization and privacy. In any case, it is excellent to have multiple choices beside other registries. I hope that other services like <a href="https:&#x2F;&#x2F;newreleases.io" rel="nofollow">https:&#x2F;&#x2F;newreleases.io</a> will catch up and support this registry as well. But, maybe this would even make them obsolete and everything a bit more centralized.

Centralisation is indeed to be concerned. I really had hopes for <a href="https:&#x2F;&#x2F;open-registry.dev" rel="nofollow">https:&#x2F;&#x2F;open-registry.dev</a>.

This is awesome! But please implement Python packaging :cry:

Please consider adding a Satis replacement for PHP Packages!

So... does this basically put Gemfury out of business?

This is really cool. I&#x27;m excited to integrate it with Nim&#x27;s package manager Nimble [1].<p>It will be a little strange though, since Nimble packages just need to be tagged in git and then you&#x27;ve got a release. It doesn&#x27;t seem that GitHub implemented it this way.<p>1 - <a href="https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;nimble" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;nimble</a>

This is very interesting. Would this also support hosting artifacts for closed source projects without having to add every user to my Github org?<p>For example, I am working on a SaaS product that can be optionally self hosted. I want to provide docker images and maven artifacts for the self hosted portion but since they are closed source I don&#x27;t think they belong on Maven Central or Dockerhub.

Will this have a container registry built in ? it mentions Docker, but not sure about the details. What about Docker image builds ?

From my perspective, it would be awesome if this could (in the future) be used to properly-host Debian and RHEL packages (extending of course to their derivatives, like Ubuntu and CentOS).<p>I wouldn&#x27;t expect that to compete with platforms like EPEL, but I think it would be great for easy distribution of programs that aren&#x27;t in those wider places.

I was really hoping they would take advantage of also housing the code to mediate some of the trust issues we&#x27;ve seen in npm: specifically, being able to prove a binary was generated from this source code. Although I imagine that&#x27;s tricky because then the build process would need to be run by them and be exposed as well..

It looks really cool. The only fear I have is the impact of mono culture if everyone starts using the same repo and it gets compromised. Having a topology of many different repos would make open source less prone to this kind of risk. That said, would be nice with a pkgsrc solution!

This is early and really depends on details, but this is a super exciting move and direction for Github. I&#x27;m wary of Microsoft ownership as it becomes even more of the home for code than before, but if they keep it true to its roots it could be a real positive.

I think it&#x27;s worth considering a different &quot;angle&quot; or emphasis on software releases.<p>This went by the other day: &quot;Software Heritage and GNU Guix join forces to enable long term reproducibility&quot; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19699031" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19699031</a><p>So that&#x27;s an interesting &quot;4 dimensional&quot; way to think about your software packaging, eh? When does it make sense to &quot;push&quot; your code to the long-term archive?<p>And this: &quot;The Great Adobe Purge of ’19&quot; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19863481" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19863481</a> and <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19888429" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19888429</a><p>Here the issue is apparently licensing.

An useful intermediate step, but ultimately, a wrong move.<p>Packages will keep having the essential problem that there&#x27;s no guarantee whatsoever that the package was derived from the advertised source. Plenty of chance for delivering malicious code.

Bet this is embargoed until the 1:30 PM PST launch. Should have gone up post launch...

I&#x27;m very curious how this will compare&#x2F;contrast with Azure Artifacts. Will it interoperate well with Azure Artifacts? Will there be guidance for when to use GitHub Package Repository and when to use Azure Artifacts?

Here’s a really good episode by the package manager-focused podcast The Manifest, about Maven with Brian Fox. <a href="https:&#x2F;&#x2F;manifest.fm&#x2F;6" rel="nofollow">https:&#x2F;&#x2F;manifest.fm&#x2F;6</a>

Now all that remains for Github to do is to add a build platform as alternative to Jenkins and a deployment framework. Source code, build platform, artifact storage and deployment - all co-located.

GitHub is amazing but is becoming the SPOF for the open source world.

This is extraordinarily generous of github, but I don&#x27;t think having a hundred maven repositories is a good idea. We have central and a process for putting signed artifacts there

&gt;Github CDN<p>Does any one know if this is actually their own CDN with PoPs around the world, of do they really mean Azure ( Microsoft ) or Fastly, which they were using at one point?

Excited to see someone other than JFrog and SonaType in this space. Personally, I think the major cloud providers are missing an opportunity by not doing the same.

Good to see them catching up on GitLab in terms of features.

Link is undead as of now for me (just switched).

This question might already be answered already, but who owns the built packages? Source code is released by license, but I don&#x27;t know whether licensing compiled packages naturally inherit the same license from source.<p>What would GitHub do in the case of a `left-pad` situation?<p><a href="https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2016&#x2F;03&#x2F;23&#x2F;npm_left_pad_chaos&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2016&#x2F;03&#x2F;23&#x2F;npm_left_pad_chaos&#x2F;</a>

So we are in the “extend” phase of Microsoft’s standard strategy? Can’t see how Microsoft replacing Maven is a good thing.

This is fantastic news!! I wish they will extend the offering to pypi hosting in the future.<p>Is this available on the Enterprise offering?

Does this mean the death of npm the company?

This is one of the services I was looking for. I&#x27;m curious to see how to community will react.<p>Thanks for sharing!

You have to authenticate to github just to install a public package with maven? What a joke.

Really cool. Hope Microsoft keeps the momentum going with releasing new features on Github.

This reminds me of GitHub’s beginnings when they were the easiest way to publish a Ruby gem

If&#x2F;when they add a build service (like Bitbucket Pipelines), they have a golden opportunity to provide a strong guarantee that a package was built from a particular Git commit (i.e. the source code wasn&#x27;t modified to add malicious code). That would make me feel a lot better about using pre-built packages.

This will eat into npmjs.com.

This solves the problem of managing private artifact repos in corp-land. If your org pays for GitHub, now you don&#x27;t have to manage them. The only thing they need now is their own CI, and maybe some improved project management, and GitHub&#x27;s going to be one gigantic gravy train.

I will now be waiting for them to add Python package support.

funny thing for js or well maybe npm you could already consume packages from github by just sayaing ```npm i -S @githubusername&#x2F;bozopackage

Can somebody explain the technical accomplishment here? What&#x27;s new about this? Github already hosts source. What do they mean by &quot;package&quot;? Is it just source? I don&#x27;t get it.

How did this launch without composer support?

This is fantastic! No more `npm link`!

Awesome! I wish pypi was there too

I did not see packaging for python

If a government gets ssl certs of github then it will possible to MITM and distribute infected deps on millions of projects.

No pip registry?

404 wizardry

No Python?

bye bye npmjs.com?

As someone else said, &quot;GOOD.&quot;