
GitHub Package Registry - rtsao
https://github.com/features/package-registry
======
dang
Blog post at [https://github.blog/2019-05-10-introducing-github-package-
re...](https://github.blog/2019-05-10-introducing-github-package-registry/).

------
ccleve
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 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'm glad that getting that artifact out wasn't an emergency.

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'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.

~~~
paulddraper
Have you tried Bintray? [1]

It's made by JFrog (makers of Artifactory), it's been around for while, it
supports lots of formats including harder ones like apt, and it makes package
distribution about as easy as it can be.

[1] [https://bintray.com/](https://bintray.com/)

~~~
Rapzid
Their support is the worst. I anticipate a 4 day turn around if I ever need to
contact them. Scary really.

Their Gradle plugin is pretty bad too; kinda ironic given their prominent
position in the Android and Java community. But then, Gradle itself is crazy
town so it's hard to blame them too much.

~~~
paulddraper
That's too bad. I've used them a lot but never had need to contact support.

------
gigatexal
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.

~~~
jackfoxy
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.

~~~
flunhat
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 apparently mixed.

~~~
koolba
I think they use SQL Server as well so there’s that poster child angle as
well.

~~~
toyg
Pretty sure it was developed entirely on the MS stack. Jeff Atwood had a few
posts about it. At the beginning it was literally one Windows Server machine.

------
diggan
It'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.

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'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.

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.

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's not worse, by it's not better either. I'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.

What I'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:
[https://news.ycombinator.com/item?id=19885502](https://news.ycombinator.com/item?id=19885502)
Website is [https://open-registry.dev](https://open-registry.dev)

It'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.

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'm
hard at work getting as close as possible, without compromising the user value
for it.

~~~
lewisjoe
First of all, thank you for building something like this. I like the idea of a
decentralized, open registry.

That said, the market's moving towards a universal registry for package
management, across tech - npm, docker, linux packages, jars etc.

With that perspective, GitLab's initiative
([https://about.gitlab.com/direction/package/](https://about.gitlab.com/direction/package/))
is something I'd likely prefer. The software's open-source and deployable,
which means the software's fate isn't tied to that of a single company.

It's already ironic enough, that the world's biggest collection of open source
projects is managed by a single closed-source software - GitHub.

~~~
diggan
Thanks a lot, always nice to hear people like it!

Yes, I agree with you. Open-Registry isn't tied to being just a JS registry.
Open-Registry focuses it's energy on unlocking the for-profit registries first
though, like npm, docker and packagist, before we'd consider moving on to
other already non-profit registries. Currently, there are no plans regarding
expanding it, but it wouldn't be very hard and the architecture of the
application makes it very easy to expand too.

While GitLabs effort is (in my mind) more well-meant than GitHubs, since it's
open source, I don't think having the software open source is enough. The full
development, funding and finance has to be open as well, and I don't think
GitLab fits that. Basically, we need Open Source Public Utilities for core
infrastructure projects like these.

Edit: Also, opened a issue in Open-Registry regarding implementing support for
more package registries here: [https://github.com/open-services/open-
registry/issues/34](https://github.com/open-services/open-registry/issues/34)

Please chime in if you think there are other registries out there than needs
to be supported by more than a for-profit entity.

------
_bxg1
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.

~~~
sho_hn
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 all happened (centralization is just so easy
and convenient; federation is _hard_ ), and it was probably inevitable in its
timeframe, but I also wish it wasn't so. It's not quite what we imagined when
we made the leap to dscms in the early aughts.

All the good stuff is still in there, though, and it's still as possible as
ever to do different things, so it's not a bleak situation.

~~~
arugulum
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 proprietary application, I
would just switch over to using regular git, and I'm guessing many others
would too.

~~~
keytarsolo
I am with you on this one. I use GitHub to share code, and participate in
projects. I use my own GitBucket instance for anything purely personal that I
don't want to lose, but don't want to make nice or document and then at work
we use GitLab.

I'm all in on git in a way that I might not have been without GitHub making it
so huge. Without GitHub, we'd probably all be using git at home but SVN at the
office.

------
franky47
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 steps in that
direction, and now package management. My guess would be for CI/CD to be next
on their list, with more integration of Azure somehow (potentially under the
hood).

~~~
keytarsolo
I'm glad you brought up Docker, but I think this is a move against GitLab,
more than it is against NPM or Docker.

Lots of us use GitLab at work because it's such a complete product. Source
code, container registry, CI/CD, Issues (via GitLab or Jira), Maven
repository, NPM repository, etc. etc.

Microsoft is trying to build out GitHub so that they can more effectively
compete for GitLab's corporate customers. Since buying GitHub they've added
many of GitLab's key features to GitHub and these are some of the biggest adds
so far.

You might be right that this hurts NPM and Docker, but I think it'll hurt
GitLab more.

~~~
orthoxerox
The price of self-hosted GitHub was so high the last time I checked that you
could buy the whole Atlassian stack or the highest tier of GitLab instead and
still have enough money left for Artifactory.

~~~
gmueckl
I guess that's their way of telling your bean counters that you don't want
self-hosted and instead want to put everything on their servers (<Jedi mind
trick wave>). That way, they can increase lock in.

------
pornel
I worry about npm now. The huge public registry everyone loves is run off
investor's money and subsidized by npm's private registry product.

But npm has recently changed their nice-people-matter CEO to a now-print-money
dude, so I suspect investors' patience has run out.

And now GitHub went directly after the one thing that npm is supposed to be
making money on.

~~~
soulofmischief
I don't worry about npm. I for one can't wait to move to a different registry.

~~~
ssalka
Same. Was hoping this would be an alternative to NPM, but it just builds on
top of it

~~~
shusson
It's an alternative to the NPM registry.

~~~
soulofmischief
Yes, parent confused me... It _is_ entirely orthogonal from NPM, correct?

~~~
pluma
It's an alternative registry so it's compatible with yarn and the official npm
client. It doesn't seem to rely on any services provided by npm Inc though, so
it's a direct competitor.

------
PureParadigm
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 the content would still be accessible.

~~~
acdha
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 you can guarantee that participating won’t
blow your ISPs data caps, interfere with other use, etc.

Abuse is the other huge problem: think about what happens when you’re hosting
some BLOBs and the FBI shows up at your door because someone uploaded some
kind of contraband and some of it was available from your IP address. How many
people are going to setup completely independent hosting accounts to avoid
fallout from something like that which happens so regularly?

The closest thing which comes to mind is the Debian mirror network and that is
something of a historical fluke, predating centralized hosting being possible,
and scoped to a much smaller set of more trusted participants. That also hits
the big problem that even with a fair amount of infrastructure backing it,
it’s hard to match the user experience of something like Github or NPM so the
most likely case is spending a lot of time in hard problems but not overcoming
the basic economics, as seems to be happening to IPFS.

~~~
momack2
I hear those concerns, but I think there are clear ways to use
decentralization to provide real benefit without running afoul of the issues
you describe. For example, you can simply cache the packages you/your team are
interested in locally, or on a shared local server for your entire office to
use - which gives you fast p2p transfers, offline resiliency, and avoids
serving any evil BLOBs or running into giant perf issues by trying to mirror
and serve the entire registry. That's the way npm-on-ipfs
([https://github.com/ipfs-shipyard/npm-on-ipfs](https://github.com/ipfs-
shipyard/npm-on-ipfs)) works - more details in this WIP blog entry
[https://github.com/ipfs/blog/pull/215/files?short_path=90aba...](https://github.com/ipfs/blog/pull/215/files?short_path=90aba38#diff-90aba38720a2fd346011d141e660c59f)
;)

~~~
acdha
A local cache helps with performance issues but you still need to get it from
somewhere, which means you’re still hoping someone else has dealt with those
issues, not to mention the cost of maintaining a high-quality robust local
server.

I’ve seen this cycle with Linux distributions, Java, and Python packages
(arguably even Git), and several digital preservation systems (I work at a
library so this is a popular topic) and each time there either ended up being
strong user demand to switch to the performance/stability/consistency of a
centralized service, that happening de-facto with one or two big players doing
most of the work, or falling apart because the contributed resources were
insufficient. Getting the incentives aligned for something like this is really
tricky.

------
mceachen
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 demo, it seems
very much like Gitlab's CI pipelines.

~~~
15characterslon
GitHub Actions are pretty neat. They were announced last year and I've started
using them a few months ago.

You can sign up for the beta here:
[https://github.com/features/actions](https://github.com/features/actions)

Introduction:
[https://www.youtube.com/watch?v=_yPml1iTbmM](https://www.youtube.com/watch?v=_yPml1iTbmM)

I'm a little bit anxious because the pricing has not yet been published. Both
GitHub Actions and package registry will be free for public repositories but
it is not yet known how much it will cost for private repositories after the
beta.

~~~
frizkie
They said they expected the package registry to be included in all paid plans.
So it's only going to cost you anything if they decide to raise prices for
everything across the board, it seems.

------
jermo
Seems like the Maven registry is susceptible to artifact hijacking.

Say I wan't to install artifacts from two GitHub users. I would have to add
these two Maven repositories:

    
    
        - https://maven.pkg.github.com/USER1 
        - https://maven.pkg.github.com/USER2
    

In that case USER1 can publish an artifact with the same groupId/artifactId as
USER2 and my Maven will happily install it without suspecting anything.

Another case - someone deletes their GH account and another user takes it:
[https://blog.sonatype.com/hijacking-of-a-known-github-id-
go-...](https://blog.sonatype.com/hijacking-of-a-known-github-id-go-bindata)

Docs: [https://help.github.com/en/articles/configuring-maven-for-
us...](https://help.github.com/en/articles/configuring-maven-for-use-with-
github-package-registry)

~~~
soulofmischief
I'm not familiar with maven, is there an equivalent of npm's scope feature?

As for account hijacking... I guess GH needs to track account deletions and
append incrementing suffixes to usernames under the repository.

~~~
jermo
There is in Gradle 5.1+ but not in Maven, afaik. They are using Maven in their
examples, however.

------
yes_man
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

~~~
rich-tea
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.

~~~
frizkie
What about GitHub makes people more likely to use Windows? Or less likely to
use Linux?

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

~~~
mceachen
Unless they require code signing, how does this help trust issues?

~~~
kevingadd
Code signing is a different sort of trust issue, in this case if the package
file is coming from the same github repo page as the source code, you know it
(AFAIK) had to come from someone with write access to the repository.

vs having an npm package named (for example) nodejs, are you sure the npm
package is authored by and owned by the same person or people that own the
nodejs git repository? How do you verify that?

There are many problems this doesn't solve of course but it does seem like it
helps with the one I describe above, the connection between the source and the
package.

Unsolved problems of course would include things like 'did someone get
unauthorized access to the git repo and put an artifact there' and 'did
someone with unauthorized access push code to the repo and then have an
artifact built'. Those are tough and real problems but I don't know if that's
any different between this and say, npm. Code signing Helps with that but you
have the same unauthorized access problem if some bad actor gets their signing
key instead of repo access.

~~~
mceachen
> How do you verify that?

I think if they required a user or org-namespaced package name, you'd get
that. For example, if [https://exiftool-vendored.js.org](https://exiftool-
vendored.js.org) was `@mceachen/exiftool-vendored`, or
`@photostructure/exiftool-vendored`, it's explicit, in the package name, who
you're trusting.

> ... did someone get unauthorized access ...

If they required publishing to be via 2FA-authenticated users, and (if I can
dream), GPG-signed commits, I think you get most of the way there.

Github is starting greenfield here, and it's frustrating they didn't (at least
afaict) require these small steps.

When I'm looking at a given package, I'd like:

1\. Assurance that the package was published by the author 2\. Assurance that
the package contents were generated, in an externally repeatable way, from a
release tag.

It seems like they could have lifted 1. by requiring 2FA and GPG.

It seems like their new Actions tab could have given us 2. It may, I can't
tell from the demo.

And when I update my dependencies, I also want to see the diffs from the
version I'm updating from. Github already has nice comparison views for
arbitrary commit shas, so this should be doable as well.

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

~~~
kenhwang
Notice how you were able to call out the de facto package manager for those
languages, but didn't for Python? I would imagine supporting the various
Python package managers in use would be a bit annoying.

~~~
mikepurvis
Third party proprietary tools like bintray/artifactory manage to do it without
too much trouble. Honestly, there aren't really that many formats to support
for Python these days— if you don't mind kicking some legacy to the curb,
sdist, bdist, and whl pretty much covers it— any other splintering of the
ecosystem is on the tooling side, but all the tools that matter still generate
one or more of those three formats as the archive.

~~~
takeda
Actually bdist is legacy is not even used anymore you basically use whl
(bdist_wheel), generate packages for specific platform and also provide sdist
(source) so people that use platform you forgot about still can use your
package. If you're lazy you can just upload sdist.

------
sambroner
This is going to be hard to avoid using for teams with a private git repo,
especially private mono repos.

The ability to provide any one with access to the repo access to the packages
created from it removes an often frustrating management step.

------
jrockway
Do I want to use Github for this? I kind of like the npm model where they say
"don't cache it, we guarantee as much capacity as you want to re-download
packages". 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.

In general, I find that caching/vendoring dependencies is the most sane thing
to do, but it'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't?

~~~
schneidmaster
> Github rate limits this

I would be shocked if GitHub rate limited this new package registry. They're
just serving tarballs and static content, and it's a new system so they can
fully architect it with scale in mind (i.e. a CDN). They rate limit current
repository-related content because they have to dynamically generate most of
it in response to requests (I assume they have caching here as well, but not
static-file-behind-CDN level caching).

~~~
jopsen
But what about repo renames... Are packages immutable?

------
whalesalad
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.

I also think that this will also have the side effect of exposing a lot of
people to package/build/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

This is going to solve a lot of problems for a lot of people.

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

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

~~~
brazzledazzle
Maybe for their SaaS but we’ll see how it’s implemented in GitHub Enterprise
for on-prem. If it’s anything like LFS you’ll just be expected to keep growing
your volume instead of doing something sane like supporting s3 or hell, even
separate volumes.

~~~
symlinkk
What's the point in running on-prem if you're just going to store large files
in S3 anyway? It makes perfect sense the way they decided on.

~~~
icebraining
Supporting the S3 API could still make sense, at least you could decouple it
and run Minio or something.

------
burtonator
... looking forward to the Hacker News post in 4 years about how Github has
really lost their way and how they're now super evil.

Remember this when you guys all rush to sign up for their new services because
it's easier for you now ;)

~~~
jeanlucas
Meh, look at npm right now. I prefer this switch even if it means switching
again in four or six years.

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

~~~
hathawsh
To host a private Python package repository, I create a simple directory tree
where the first level is the package name and the second level is the package
(a tarball, zip, or a wheel) and I serve that tree over HTTPS using vanilla
Apache or nginx with directory listings enabled. Then I use "bin/pip -i
[https://packages.example.com](https://packages.example.com) ..." to point to
that repository. It's very low tech and it turns out that's all I need.

Whenever pip can't find a package due to case or hyphen issues, I look at the
access log, find out what pip is trying to retrieve, and rename things or use
symlinks to fix it. Also, I manage the directory using git. (One of these days
I'll try using git-annex or similar, but for now, a few gigabytes is not even
close to being a burden.)

~~~
uranusjr
Yeah, self-hosting a Python package index is so easy that (free) hosting
solutions don’t really offer much, which is probably why you don’t see many of
those. Paid services do exist (the most recent is PyDist), but you’re really
paying more for hosting than the index.

p.s. I believe pip has recently fixed the hyphen problem you mentioned. Sorry
for the inconvenience! Please do report any issues if they still exist.

------
nathan_f77
I'm working on a SaaS service for developers, so I'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.

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.

[1] [https://github.com/OpenAPITools/openapi-
generator](https://github.com/OpenAPITools/openapi-generator)

------
jeremiahlee
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.

~~~
andreineculau
100% agree with you.

Take the JS world for instance, npm is many good&bad things, but one thing
that was squeezed in the package.json spec is the ability to install packages
from git repositories. And so, github already had a "package registry" for
npm, and we publish npm packages to github without needing extra credentials,
etc.

Granted npm could add a command "publish-to-git", or allow setting the
repository to a github url, but a simple tool like
[https://github.com/andreineculau/npm-publish-
git](https://github.com/andreineculau/npm-publish-git) does the job (it's
regularly used and tested within my current company TobiiPro
[https://github.com/tobiipro](https://github.com/tobiipro)).

------
mmcclellan
Watching the live stream now ([https://live-stream.github.com/](https://live-
stream.github.com/)). Will likely use the Docker support near immediately.
Hoping Singularity will be supportable as well.

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

~~~
prh8
What does Gitlab have that this is competing with? I know Gitlab's docker
registry but not of a package registry.

~~~
foxylion
Yes, it has a package registry feature for NPM and Maven:

Maven:
[https://docs.gitlab.com/ee/user/project/packages/maven_repos...](https://docs.gitlab.com/ee/user/project/packages/maven_repository.html)

NPM:
[https://docs.gitlab.com/ee/user/project/packages/npm_registr...](https://docs.gitlab.com/ee/user/project/packages/npm_registry.html)

~~~
sytse
GitLab released integrated packaging back in 2016 - starting with a Docker
registry - and adding Maven and NPM in 2018. You can find our plans for adding
further packaging capabilities on our public packaging roadmap
[https://about.gitlab.com/direction/package/](https://about.gitlab.com/direction/package/)

We are also embarking on making package management more secure and auditable
for the users of packages with a Dependency Proxy
[https://about.gitlab.com/direction/package/dependency_proxy/](https://about.gitlab.com/direction/package/dependency_proxy/)
GitLab users will be able to block and delay packages that are suspect and
trace where vulnerable packages were used. This will increase performance,
cost efficiency, and the stability of your tests and deployments.

~~~
jbergstroem
> GitLab released integrated packaging back in 2016 - starting with a Docker
> registry - and adding Maven and NPM in 2018.

No, first version with "NPM support" (see my other comment as why I don't
consider it being "supported") was gitlab 11.7, end of january 2019. I was
really looking forward to this and were following your verdaccio (an open
source npm registry) thread closely. Development then made a 180 and chose to
re-implement rudimentary support for npm on top of your current package
abstraction instead.

~~~
sytse
Oops, you're correct that 11.7 was the first release, sorry for messing up the
timeline.

------
localhostdotdev
debian packages are also supported it seems: [https://github.com/git-lfs/git-
lfs/packages/5789](https://github.com/git-lfs/git-lfs/packages/5789) and
[https://github.com/alteregofun/firsty/packages/2953](https://github.com/alteregofun/firsty/packages/2953)

found a ruby one:
[https://github.com/wintron/hola/packages/4057](https://github.com/wintron/hola/packages/4057)
(yes! got it working)

------
fooey
It's up now

[https://help.github.com/en/articles/about-github-package-
reg...](https://help.github.com/en/articles/about-github-package-registry)

Supports NPM, Docker, Maven, Nuget, RubyGems

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

~~~
mfatica
The same way it works today when you utilize packages from multiple
repositories. Github isn't the first non-npm repository in existence.

~~~
jonnyscholes
What if they clash (eh user/package exist both on npmjs.com and GitHub)? Does
it go through each of the configured repositories in sequence looking for a
match?

~~~
adamscybot
You configure the NPM client on what your primary registry is. I think this
github repo will mirror everything on NPM (?).

~~~
runeb
That will cause crashes between username scopes on npmjs and GitHub

------
lonnyk
It's always odd to me that PHP is left out of things like this. What do these
other package managers have that Composer doesn't?

~~~
kyriakos
Python is left out too. It's a beta release so maybe they are not done yet.

------
keerthiko
I'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.

This makes it less of "gitlab or github?" and allows developers to more easily
decide to use just one for each project based on whichever service better
focuses on the project's primary long-term goals.

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.

------
fouc
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.

~~~
nirvdrum
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.

------
agentofuser
Helping decentralize package managers is Protocol Labs' top priority for IPFS
in 2019[1].

Seems very prescient now. Hopefully this gets adopted soon enough, while it's
still easy to batch-export stuff out of registries. I really don't want MS
owning the most popular editor, git host, "linux desktop", _and_ universal
package manager in the world. Edit: oh, and programming language (typescript
is eating javascript.)

[1]: [https://github.com/ipfs/package-
managers](https://github.com/ipfs/package-managers)

------
vladimir-y
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't want to expose
the entire GitHub account to Travis CI but allow only publishing to the
registry. So if the GitHub key/access-token leaks somehow the possible damage
would be limited by registry publishing scope. So something like scoped access
tokens.

~~~
rustyfe
Yes. They showed in the demo that there will be a new scope for read/publish
packages. So you can create a personal access token for Travis with only that
scope.

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

~~~
rexpop
That's how big a deal it is.

------
tech_tuna
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.

------
chriskinsman
Link doesn't go anywhere?

~~~
zimbatm
Looks like it's going to be released soon:
[https://news.ycombinator.com/item?id=19881693](https://news.ycombinator.com/item?id=19881693)

------
pythonist
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 [https://newreleases.io](https://newreleases.io) will
catch up and support this registry as well. But, maybe this would even make
them obsolete and everything a bit more centralized.

------
kostarelo
Centralisation is indeed to be concerned. I really had hopes for
[https://open-registry.dev](https://open-registry.dev).

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

------
Roritharr
Please consider adding a Satis replacement for PHP Packages!

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

~~~
rykov
Gemfury supports Python, so OK for now.

------
dom96
This is really cool. I'm excited to integrate it with Nim's package manager
Nimble [1].

It will be a little strange though, since Nimble packages just need to be
tagged in git and then you've got a release. It doesn't seem that GitHub
implemented it this way.

1 - [https://github.com/nim-lang/nimble](https://github.com/nim-lang/nimble)

------
vbsteven
This is very interesting. Would this also support hosting artifacts for closed
source projects without having to add every user to my Github org?

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't think they belong on
Maven Central or Dockerhub.

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

------
CaliforniaKarl
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).

I wouldn't expect that to compete with platforms like EPEL, but I think it
would be great for easy distribution of programs that aren't in those wider
places.

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

------
hestefisk
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!

------
adjkant
This is early and really depends on details, but this is a super exciting move
and direction for Github. I'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.

------
carapace
I think it's worth considering a different "angle" or emphasis on software
releases.

This went by the other day: "Software Heritage and GNU Guix join forces to
enable long term reproducibility"
[https://news.ycombinator.com/item?id=19699031](https://news.ycombinator.com/item?id=19699031)

So that's an interesting "4 dimensional" way to think about your software
packaging, eh? When does it make sense to "push" your code to the long-term
archive?

And this: "The Great Adobe Purge of ’19"
[https://news.ycombinator.com/item?id=19863481](https://news.ycombinator.com/item?id=19863481)
and
[https://news.ycombinator.com/item?id=19888429](https://news.ycombinator.com/item?id=19888429)

Here the issue is apparently licensing.

------
vemv
An useful intermediate step, but ultimately, a wrong move.

Packages will keep having the essential problem that there's no guarantee
whatsoever that the package was derived from the advertised source. Plenty of
chance for delivering malicious code.

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

------
WorldMaker
I'm very curious how this will compare/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?

------
brianzelip
Here’s a really good episode by the package manager-focused podcast The
Manifest, about Maven with Brian Fox.
[https://manifest.fm/6](https://manifest.fm/6)

------
noisy_boy
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.

~~~
ToFab123
Azure Pipelines? [https://azure.microsoft.com/en-
us/services/devops/pipelines/](https://azure.microsoft.com/en-
us/services/devops/pipelines/)

~~~
noisy_boy
It looks interesting though has the extra Azure dependency. Jenkins doesn't
have any such requirements.

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

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

------
ksec
>Github CDN

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?

~~~
anticensor
Dedicated instances in Azure cloud.

------
numbsafari
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.

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

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

------
yingw787
This question might already be answered already, but who owns the built
packages? Source code is released by license, but I don't know whether
licensing compiled packages naturally inherit the same license from source.

What would GitHub do in the case of a `left-pad` situation?

[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

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

~~~
pluma
Any recent examples of Microsoft using EEE? All examples I can think of are
from the 90s or very early 00s.

------
didip
This is fantastic news!! I wish they will extend the offering to pypi hosting
in the future.

Is this available on the Enterprise offering?

------
polskibus
Does this mean the death of npm the company?

------
bitfox
This is one of the services I was looking for. I'm curious to see how to
community will react.

Thanks for sharing!

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

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

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

------
Qerub
If/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't modified to add malicious
code). That would make me feel a lot better about using pre-built packages.

~~~
meddlepal
GitHub Actions?

~~~
Qerub
Hah, I had forgotten about that. Now they just have to integrate all the
services and provide opt-in public traceability for source -> action(s) ->
registry.

------
sebringj
This will eat into npmjs.com.

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

~~~
brazzledazzle
They have Actions which can function as a basic CI.

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

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

------
tantalor
Can somebody explain the technical accomplishment here? What's new about this?
Github already hosts source. What do they mean by "package"? Is it just
source? I don't get it.

~~~
seaish
With the npm example, you can tell npm to use github's package repo instead of
npmjs.com, and install from or publish to that one instead. Basically another
npm, but the same command line app.

~~~
tantalor
Why is that useful?

~~~
ht85
One use is that you can point to any commit, but npm will only have versions
that were explicitly released to it.

Another reason would be having a few private packages and not wanting to
manage an entire npm account for them.

------
systematical
How did this launch without composer support?

------
wintorez
This is fantastic! No more `npm link`!

------
tarasmatsyk
Awesome! I wish pypi was there too

------
bobquest33
I did not see packaging for python

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

~~~
eitland
Same as if they pwn debian, redhat, docker, npm, maven (also used by gradle)
or Microsoft Windows update infrastructure then?

Or am I missing something?

~~~
sanbor
Yes, but instead of having two pwn 5 now they just have to pwn 1.

~~~
eitland
Still don't get it, if you pwn any of the above it is game over for a 10-30
percent of all computers.

Same with GitHub packages, you'll have the possibility to a large number of
projects, but far from all IMO.

------
nurettin
No pip registry?

------
orliesaurus
404 wizardry

------
dfilppi
No Python?

------
ezekg
bye bye npmjs.com?

~~~
nubs
I think the National Association of Pastoral Musicians will be fine. I assume
you meant npmjs.com. :)

~~~
m463
meanwhile the International Brotherhood of Magicians has faded into obscurity.

------
whatever_dude
As someone else said, "GOOD."

------
heinrichhartman
What a move! :clap: :clap: :clap:

Apparently Microsoft has a few spare disks in their Cloud :)

