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

321–330 of 389 posts

Re: GitHub Package Registry

#321

Post by jermo »

soulofmischief wrote: post #319
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.

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

Re: GitHub Package Registry

#322

Post by jopsen »

schneidmaster wrote: post #80
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…

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

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

Re: GitHub Package Registry

#323

Post by ngngngng »

memmcgee wrote: post #220
owaislone wrote: post #83

Earlier quoted context omitted.

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…

Doesn't Go already download packages from GitHub?

Yes, Go uses git repo paths to download source code.

Re: GitHub Package Registry

#324

Post by bengale »

diggan wrote: post #316
dtech wrote: post #313

Earlier quoted context omitted.

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

I think this is somewhat mitigated with Microsoft these days because of their motivations for buying GitHub. For them this endeavour seems to be focused on winning developers hearts and minds rather than seeing how much profit they can make from it. Clearly they have a business case for this, but it seems more to be more geared towards making azure more and more profitable instead.

Re: GitHub Package Registry

#325

Post by toyg »

akavel wrote: post #271
soulofmischief wrote: post #213

Earlier quoted context omitted.

A git service built on IPFS or something similar would be wicked. It does take quite a bit of engineering (money) to compete with the big boys, however.

There's a Git application on Scuttlebutt, already used by people in the community - see e.g.: https://github.com/noffle/git-ssb-intro

> anybody can push to anybody else's git repository. [...] The nomenclature is to treat the ssb remote as the "true" remote, and work off of a branch called @your-username/master as your own master, emulating a forked repo. This seems to work well: the SSB network thrives off of being a group of kind, respectful folks who don't push to each other's master branch. :)

Uh, thanks but no thanks. I thought we had learnt that the honor system does not scale.

Re: GitHub Package Registry

#326

Post by rectang »

rswail wrote: post #274
rectang wrote: post #165

Earlier quoted context omitted.

I don't think developers should place too much trust in any platform vendor. (Apple and Swift, Apple and Metal, Google and AMP, Google and Dart, Amazon and AWS... the list is endless.) Their interests are fundamentally at odds with ours. Platform vendors benefit when developers are locked in by network effects. Developers maximize their value when their skills are transferable. And that goes for Github and its packag…

Except that in the commerical software world, you can't stay independent with "purity". The costs of supporting multiple cloud providers is still a cost. K8S, Docker, Pulumi, Packer are starting to reduce that interoperability gap, but it's still a friction. I've moved to .NET on Ubuntu for our current project (I'm an Engineer Manager/Architect, but the team is C#). It's been remarkably smooth and low friction. So it…

In the abstract, what would best serve developer interests is if platforms are as compatible as possible, especially in their superficial details. That minimizes switching costs, both in terms of what it takes to port real software from one platform to another, and in terms of what a developer must learn to apply what they already know when working with a new platform.

Taken to an ad absurdum conclusion, developers want all platform vendors to coordinate in order to minimize switching costs. Of course there are lots of good reasons such a level of coordination will never be realized. :)

In the meantime, there will always be efforts to create adapters which generalize the interfaces of multiple platforms and put them behind a common wrapper interface. But while such interoperability efforts serve developer interests, they work against the interest of vendors in encouraging platform lock-in.

The dynamic isn't pure in terms of real product offerings because vendors also understand that portability provides value to developers, and so some vendors will provide at least some portability in order to differentiate themselves. But I maintain that the fundamental interest structure is unchanging.

Re: GitHub Package Registry

#327

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

Re: GitHub Package Registry

#328

Post by noisy_boy »

ToFab123 wrote: post #207
noisy_boy wrote: post #201

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.

Azure Pipelines? https://azure.microsoft.com/en-us/services/devops/pipelines/

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

Re: GitHub Package Registry

#329

Post by noisy_boy »

josegonzalez wrote: post #230
noisy_boy wrote: post #201

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 Actions?

I'll explore it further. Seems like it is in public beta stage right now.

Re: GitHub Package Registry

#330

Post by toyg »

soulofmischief wrote: post #272
chupasaurus wrote: post #217

Earlier quoted context omitted.

The first project provided by DDG to me was Radicle[ https://radicle.xyz/ ]

rad project allows you to create, checkout, manage, and publish a project, comprised of issues, patch proposals, and a git repo. Well hot dog. And it uses LISP for scripting? Nice. Interesting approach to saving state, too.: One only needs the address of the latest input, the "head", to be able to recover the whole log. The owner of a machine uses an IPNS link to point to the head of the list, and the name of this li…

It looks the business but it lacks the single most important feature for popularity: a GUI. GitHub made Git dominant by building a friendly GUI on top of it. Before, it was just another player in a relatively crowded field of CLI DVCSs. Obviously it is not essential to get stuff done, but anything with any ambition of generating network effects definitely needs a GUI.

The other thing that seems to be lacking, from a quick reading of the docs, is a way to generate pull requests (or "patches" in Rad terms) from a branch, and then merge them on another branch. Obviously you can do it manually in git, but GH is definitely a superior experience.

Post reply on HN