FWIW, Software Heritage already has your github repos: <a href="https://www.softwareheritage.org/" rel="nofollow">https://www.softwareheritage.org/</a><p><a href="https://hn.algolia.com/?query=Software%20Heritage&sort=byPopularity&prefix&page=0&dateRange=all&type=story" rel="nofollow">https://hn.algolia.com/?query=Software%20Heritage&sort=byPop...</a><p>And GNU Guix at least will transparently fallback to them:<p>> Since Software Heritage archives source code for the long term, Guix can fall back to the Software Heritage archive whenever it fails to download source code from its original location. The way this fallback has been designed, package definitions don’t need to be modified: they still refer to the original source code URL, but the downloading machinery transparently comes to Software Heritage when needed.<p><a href="https://www.softwareheritage.org/2019/04/18/software-heritage-and-gnu-guix-join-forces-to-enable-long-term-reproducibility/" rel="nofollow">https://www.softwareheritage.org/2019/04/18/software-heritag...</a>
> <i>is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects.</i><p>I am... really confused by this.<p>Isn't this just Github? <i>Github</i> is a hosting service that allows you to host your packages and code in one place. It has testing and publishing pipeline support, you can add artifacts/releases, make your packages private or public, host different types of software at the same time, and it's compatible with most existing dependency systems, including NodeJS.<p>I can see this has more download statistics, which is nice. And it has a policy that artifacts can't be deleted, which is very nice.<p>Is that it though? I know I have to be missing something; what can I do now that I couldn't already do with Github as is?
Looking at the ruby docs, my interpretation is that if a gem is published only on github registry, there's no good way to use it as an indirect dependency (no good way for a gem to list it as a dependency) -- any app using such a thing would have to know the list of all of these indirect dependencies on github registry, and list them individually in the top-level Gemfile, along with their correct github source.<p>This seems to limit the utility for ruby. I'm not sure if other supported platforms have similar issues?<p>You could already do a lot of what github registry for ruby does by using an existing feature where you could already point to a git repo (not just GH) in your `Gemfile`. What this adds is just the ability to resolve multiple versions from github using ordinary rubygems resolution. The existing feature forced you to manually specify a tag (hoping there was a predictable tag for a version) or SHA, or use whatever is on master HEAD.
Deja vu <a href="https://github.blog/2008-04-25-github-s-rubygem-server/" rel="nofollow">https://github.blog/2008-04-25-github-s-rubygem-server/</a><p>And then removed 16 months later: <a href="https://github.blog/2009-10-08-gem-building-is-defunct/" rel="nofollow">https://github.blog/2009-10-08-gem-building-is-defunct/</a><p>Hopefully this one lasts longer.
There's no immediate mention of this on the site, but -- why did they select the package formats that they did?<p>I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?
At least in the case of NPM (I don't know as much about the other ones): Doesn't that create a huge opportunity for hijacking attacks, where someone publishes a malicious NPM package in the default NPM registry under the scope identical to a Github organization/username?
Any word on trying to tackle package build verification/reproductibility so users can be guaranteed that the package was built from the source code?<p>The problems like with rubygems from yesterday and npm a few weeks back would be gone with something like that.
Deleting packages is not supported. Sobhow to handle a compromised package? Looks like you have to contact github and hope the act fast.<p>Oh, and no pip registry :(
Any word on what the price will be for private repos after the beta ends?<p>Would be interesting to see how it compares to Docker Hub for hosting private images.
I came across this one the other day, which looks like it does this plus producing the binary package for you:<p><a href="https://jitpack.io/" rel="nofollow">https://jitpack.io/</a><p>(No, I'm not related to that company in any way. I just saw it yesterday and thought it seemed like a neater solution.)
I hope they add robots accounts like Quay.io (<a href="https://docs.quay.io/glossary/robot-accounts.html" rel="nofollow">https://docs.quay.io/glossary/robot-accounts.html</a>).
I believe it's going to affect the whole developer community in a bad way.<p>Right now, all the major package manager are indirectly making each other better, they experiment, improve and borrow good ideas from each other. It's open-source and there is a little barrier for developers to contribute.<p>If n years from now GitHub becomes the defacto standard for package managers and replaces all the existing ones the further innovation will be much slower.<p>It might transform into "Want to improve package managers? You have to work for Microsoft"
The lack of "the" makes this read a bit weirdly:<p>>GitHub Package Registry allows you to develop your code and host your packages in one place. You can use packages from GitHub Package Registry as a dependency in your source code on GitHub.<p>"Package registry" is a fairly generic term, so to me it would be natural to refer to this product as "the Github package registry" (capitalized or not).<p>Is there a name for deliberately avoiding "the" in this way?
For all the features GitHub has, this is the only one that myself and those that I know personally have made us care and watch <i>very</i> closely what GitHub does with this.<p>We've been looking for a simple way to streamline releases. Right now everything we have at my job is on GitLab and I use GitLab personally (though I have a github account, of course).<p>I prefer GitLab in every way, but this feature alone might be a good enough reason to switch. It would make releases just <i>so darn easy</i>. The only thing I hope (which is not made clear) is that the stipulation that you can't easily delete a package on the registry (According to the link, its only for GDPR requests and legal reasons) is something that, for instance, an Enterprise account wouldn't have. I already have our purchasing team looking into it, thats how serious this is.<p>If the API for hitting these packages is any good, its gonna be so hard to resist.<p>I really hope GitLab has a good response to this.<p>To wit, since GitLab is custom hosted, I wonder how hard it would be to add this into the CE edition....<p>With all that said, I wonder what the hidden limits will be. Imagine if instead of NPM maintaing all of its servers, it was just a thin database that had better routing to github releases? Would that fall afoul with GitHub?<p>I mean, whats the point of maintaining your own distribution server when GitHub can front all the hosting costs and all you have to do is map the name of a package to its Github Package Release URL. I could see NPM, PyPI et. al. just doing that, instead of having their own servers. Maybe its a good idea to run additional cache nodes, but GitHub being the main place where release code lives for you package index would cut the bills significantly no?
Github is going to be the source of code and data that neural networks use to write software. There is so much data on there, and it will only increase. There's only so many coding patterns. Get ready to be a fill in the blanks developer
Honestly, GitHub has been going down hill for about 18 months now. It all started with the ":D Set status" feature. I give it another two years before Microsoft has officially turned GitHub into a 2021 version of Skype