Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub Package Registry

github.com

Post reply on HN
Print view View original

191–200 of 389 posts

Re: GitHub Package Registry

#191

Post by SOLAR_FIELDS »

SOLAR_FIELDS wrote: post #139
djsumdog wrote: post #98

Earlier quoted context omitted.

Yea same here. There are way too many workflows already setup around Maven Central. People publish to it from Scala/SBT, Gradle, Clojure/Leiningen, Kotlin, etc. It's not going to be going anywhere any time soon.

Exactly. It’s nice to have competition in the Java package space aside from Maven, Jfrog Artifactory and Nexus. It will take time to build up network effects for Github but if they make a good product I could see it happening eventually. We use Artifactory where I work and the generic aspect of it plus the ecosystem integrations are super nice. I can publish docker images, regular zip files, jar files, Python package…

Too late for me to edit, but it looks like gitlab has been working on this too and published a response: https://about.gitlab.com/2019/05/10/github-adds-package-regi...

It looks like from that post they only support Docker, Maven and NPM right now so they also have some catching up to do in the genericization world.

Re: GitHub Package Registry

#193

Post by frizkie »

owaislone wrote: post #83
mikepurvis wrote: post #24

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

Github has traditionally been a Ruby shop and once you are a Ruby shop, you can use Ruby to do anything that you could use Python for so there is no need to touch Python other than may be data science. That means they would have built a lot of expertise in Ruby and comparatively very little with Python. So it's understandable that they are able to add support for Ruby before python. It must have been easier to do for…

I'm puzzled by the fact that you've been downvoted, as far as I can tell everything you've said is valid, and certainly not anti-python.

Re: GitHub Package Registry

#194

Post by [deleted] »

toyg wrote: post #174
koolba wrote: post #112

Earlier quoted context omitted.

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

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.

[deleted]

Re: GitHub Package Registry

#195

Post by zmix »

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

This!

Hypothetically, and, currently, only hypothetically:

If Microsoft is still of the old spirit, then what we see now, would be the biggest "Embrace, Extend, Extinguish" coup, they have ever done.

It won't happen now, it won't happen tomorrow. For that, this would be too big of an effort. But Microsoft is trying big to win back the hearts of "The Community" and "The Market". As people, especially developers, have gotten more clever about the computers, since the advent of the web has made it possible, to live in IT without "getting shown" and "taught" by "Big Daddy" type companies, since all and everybody is much more self-organizing these days, there is much more competition to MS, that has been in the past. So they try to get it back, what they have lost.

* VSCode, is very sweet and candy, with lots of bells and whistles, major software companies writing plugins for it (the most active being Microsoft). As a programmer's text editor it sits right at the core of every development. VSCode, especially, is attractive to people outside of MS Windows (they might use VisualStudio). I am talking about web- and "App" developers. Mostly frontend or mobile. * By buying Github, they bought the "source of all sources". They won't ever own the code, but as long as they own the popular infrastructure, everybody is playing on their grounds. The next step, in two years, or so, may be the need for a MS account to log into Github. They integrate it.

Out of curiosity, what else did MS buy in the last years, that would fit into this pattern?

Re: GitHub Package Registry

#196

Post by seaish »

tantalor wrote: post #189

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.

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.

Re: GitHub Package Registry

#197

Post by tantalor »

seaish wrote: post #196
tantalor wrote: post #189

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.

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.

Why is that useful?

Re: GitHub Package Registry

#198

Post by ht85 »

tantalor wrote: post #189

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.

Packages are different.

For npm, you might publish your source 1:1 if you have a very vanilla setup, but a typical package in npm contains a built version of the code while the repo contains source, documentation, tooling, etc.

Package versions are also created explicitly and tend to contain many changes, whereas repos are commit/branch based.

Re: GitHub Package Registry

#199

Post by ht85 »

tantalor wrote: post #197
seaish wrote: post #196

Earlier quoted context omitted.

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.

Why is that useful?

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.

Post reply on HN