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

311–320 of 389 posts

Re: GitHub Package Registry

#311

Post by shagie »

ccleve wrote: post #31

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 ot…

> It will mean the death of Maven Central, about which I have mixed feelings

I don't see it as such. A key reason that this offering from GitHub (and the corresponding one for GitLab) is useful is that it simplifies the enterprise stack - things that will never get posted to Maven or npm or DockerHub in the first place.

From the announcement:

> Packages in GitHub inherit the permissions of the repository, and you no longer need to manage third party solutions and sync team permissions across systems.

This impacts locally hosted Nexus repositories. The artifacts that I build for my team that currently get pushed to internal systems can now live along side the source code repository.

From the "What our customers are saying":

> GitHub Package Registry has allowed us to spend more time solving hard problems, and improving patient care. Since it uses the same permissions and security as the rest of GitHub, we spend less time managing multiple accounts, ACLs, and on-premise infrastructure, which leaves us with more time to code what matters!

That is exactly where it is useful.

For maven central, I am pleased to have the governance and management of those systems be part of my deployment chain for third party libraries and I will continue to prefer to pull something from Maven Central rather than somewhere else whenever possible.

Re: GitHub Package Registry

#313

Post by dtech »

diggan wrote: post #283

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…

> 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 actually think Github might be different, because they have a pretty solid monetization model already: companies paying per user for private source repositories. This easily extends to companies private artifact repositories.

Github benefits from the network effect of providing free source repositories to open source projects, so this is probably enough incentive to start and keep providing high-quality free artifact repositories to open source projects.

Re: GitHub Package Registry

#314

Post by diggan »

AsyncAwait wrote: post #309
diggan wrote: post #283

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…

Hey, love projects like yours, keep it up!

Thanks a lot for the kind words! Makes my heart all warm and fuzzy.

Re: GitHub Package Registry

#315

Post by DaiPlusPlus »

dend wrote: post #244
DaiPlusPlus wrote: post #153

Earlier quoted context omitted.

Question: Why is Offline documentation and the Help Viewer in Visual Studio 2017 still horribly broken? I keep it around for when I don’t have internet access but it’s next to useless. Why keep up the pretence? (In comparison, the CHM and DocEx from VS6 through VS2008 work perfectly and are very reliable)

What particular aspect of it is broken? Genuinely asking the question, because I want to make sure we address major issues in the customer experience that you have.

Massive amounts of duplicated content. Broken images and stylesheets. I’ve downloaded all content but pressing F1 on a symbol in VS informs me the content is only available online.

Re: GitHub Package Registry

#316

Post by diggan »

dtech wrote: post #313
diggan wrote: post #283

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…

> 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 actually think Github might be different, because they have a pretty solid monetization model already: companies paying per user for private source repositories. This easily extends to companies private artifact repositories. Github benefits from the n…

Yeah, today that's so. The problem with for-profit companies is that there is nothing keeping that from staying like that, except the goal of earning a profit.

The moment the outlook of earning a profit changes, the company has to adjust and sometimes that doesn't affect the users. But sometimes it does, and it's those cases Open-Registry is trying to prevent from ever happening.

Let's say the community comes up with a feature that would be great for the GitHub Package Registry to provide, but it would make the earnings from private repositories lower. Since GitHub rely on earning from private repositories, the decision will probably be to not implement that feature, even though it would be good for the Package Registry users.

Re: GitHub Package Registry

#317

Post by windexh8er »

rich-tea wrote: post #252
jrockway wrote: post #44

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 hap…

Why does every docker image build have to pull the packages? Are you force rebuilding and defeating docker's cache mechanism?

This isn't too surprising. Microsoft's DevOps in Azure does the same thing (or did I haven't looked at it in a few months). There was literally no point in using it until, as you've pointed out, a user can leverage cache. If I have a multistage build with an SDK that weighs in around 1GB why would I ever want to use a tool that pulls that down every run?

I think, as many have said, that this is going after GitLab more than anyone else, although I can see a lot of users migrating away from Docker Hub given 1) the latest snafu/breach and 2) why keep my container repo over here and my container build pipeline over there? Doesn't make any sense and Docker Hub doesn't come with the pedigree of CDN baked in. I'm sure the same arguments work for other technologies in this consideration, but... Docker seems to continually be behind the 8-ball on the shifting field. My guess is Microsoft buys them in the next 3 years at a discount anyway. It fits their pattern of getting in front of the modern ecosystem and since Docker has leverage with containerd right now it would be an unsurprising move.

Re: GitHub Package Registry

#318

Post by 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.

Re: GitHub Package Registry

#319

Post by soulofmischief »

jermo wrote: post #308

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 - someon…

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.

Re: GitHub Package Registry

#320

Post by ksec »

okasaki wrote: post #299
ksec wrote: post #242

Earlier quoted context omitted.

>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. Yes, Active X, Windows, Java etc, and god knows how many awful things they did I cant remember them all. But years later Bill Gate decide to donate his wealth to good cause. Not only is this not a PR / Marketing Stunt, h…

> But years later Bill Gate decide to donate his wealth to good cause. Did he? Bill Gates has consistently been getting richer according to Google, and now has a staggering 90B.

https://en.wikipedia.org/wiki/Bill_%26_Melinda_Gates_Foundat...
Post reply on HN