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

The GitHub registry public beta is live

help.github.com

Post reply on HN
Print view View original

91–100 of 137 posts

Re: The GitHub registry public beta is live

#91

Post by matthewbauer »

jolmg wrote: post #46
carapace wrote: post #36

FWIW, Software Heritage already has your github repos: https://www.softwareheritage.org/ https://hn.algolia.com/?query=Software%20Heritage&sort=byPop... And GNU Guix at least will transparently fallback to them: > 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 fallbac…

You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Fire…

I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need some more complex constaint solving on top of your commits to figure out what works.

I would prefer doing it based on the 6-month release channels, so you get multiple version for every 6 months. You end up with some gaps between versions, but also have more guarantees everything actually works together. Basically "nix search" with multiple channels.

I actually had to do something similar with GHC versions for a project of mine. It turns out you can run Nixpkgs all the way back to the first release in 13.10 (LC_ALL=C is needed). Obviously not that long ago right now, but it should continue to work as time goes on & give us 10+ years.

https://gist.github.com/matthewbauer/ecdb665f84b7f6100f3f6e3...

Re: The GitHub registry public beta is live

#92

Post by jrochkind1 »

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.

This seems to limit the utility for ruby. I'm not sure if other supported platforms have similar issues?

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.

Re: The GitHub registry public beta is live

#93

Post by jonny383 »

dstaley wrote: post #70
jonny383 wrote: post #69

Earlier quoted context omitted.

This is a glorified wrapper written around existing package managers. I wouldn't call that useful.

No, this is a reimplementation of basically every major package server. Now, instead of hosting your Ruby gems on rubygems, NPM packages on the NPM registry, and Python packages on PyPI, you can host them directly alongside your source code. The tools by which you access these package registries are the same, but they can now be backed directly by GitHub.

Which is a glorified wrapper. Why on earth would you make a decision to lock up all of your eggs in the Microsoft basket? Diversity is a good thing. Just look at what's happened to the web industry with Chrome, and now it's basically too late.

Re: The GitHub registry public beta is live

#94

Post by jrochkind1 »

psadauskas wrote: post #82

Deja vu https://github.blog/2008-04-25-github-s-rubygem-server/ And then removed 16 months later: https://github.blog/2009-10-08-gem-building-is-defunct/ Hopefully this one lasts longer.

i would say that went away because the rubygems ecosystem (including the invention of bundler) improved enough that there was really no reason to use github as your rubygem server. It didn't give you anything but a slightly confusing proprietary alternative with no added value. So people rightly stopped using it, and it rightly went away.

It's not clear to me what the value added for ruby specifically is now. (Yes, I know rubygems.org has problems; but this has feature problems with indirect dependencies compared to rubygems.org hosting).

Re: The GitHub registry public beta is live

#95

Post by matthewbauer »

matthewbauer wrote: post #91
jolmg wrote: post #46

Earlier quoted context omitted.

You know what'd be really cool? For either Nix or Guix to transparently support installation of any version of any program without hacks like putting an alternate version under a different name or some such. I wish programs didn't require continued maintenance for dependency updates or risk being uninstallable without putting them and a number of dependencies under different package names. I wish I could install Fire…

I think a tool like that could be very useful! The main issue with basing it off of Git commits is that there is no guarantee that the last commit with a given version is actually a good version. Consider the case where a-1.0 depends on b-1.0 and b is updated to b-2.0 in a commit so that a is not compatible with b-2.0. Even though a-1.0 is still around, it's not going to work until we update it to a-2.0, so you need…

I have a quick mockup of something like this in Nix:

https://gist.github.com/matthewbauer/7c57f8fb69705bb8da9741b...

It keeps makes past versions of packages available to you, but does not really help with discoverability.

Re: The GitHub registry public beta is live

#96

Post by judge2020 »

IggleSniggle wrote: post #44
hobofan wrote: post #17

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?

Maaaaaaybe. But I don’t think so in practice. At least not yet. Would probably be good to see package.json evolve to allow specification of registry. In my personal experience of using a private npm registry, you pay a lot more attention to package-lock. package.json could probably evolve to specify registry in a similar way.

Considering the npm corporation had layoffs[0], and how they haven't merged any PRs from outside sources in a while (this may have changed, but here's an example[1]), They might not be stoked to reduce the friction of linking to other package repositories from withing package.json.

0: https://hub.packtpub.com/surprise-npm-layoffs-raise-question...

1: https://github.com/npm/cli/pull/125#issuecomment-474127391

Re: The GitHub registry public beta is live

#97

Post by bad_user »

ageofwant wrote: post #42
bad_user wrote: post #28

Earlier quoted context omitted.

Also, most importantly, Git repositories are not immutable and any package repo that's not immutable is a terrible, terrible idea

git repos can be as immutable as you want. you just need to point your package manager to a commit or tag, instead of a branch head. if you are worried about a rebase, well you have that issue with any public artefact stores.

The point is that it's not your Git repo, usually, when talking of dependencies, so it's not really about what you want.

SHAs can't be changed, but they can be deleted. And on GitHub, entire projects, usernames, orgs can be deleted. Or renamed. In case of a user rename, GitHub does maintain redirects for awhile. Until that username is taken by somebody else.

Re: The GitHub registry public beta is live

#99

Post by tehbeard »

jrochkind1 wrote: post #92

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

Other platforms (maven/java comes to mind) benefit somewhat due to the compiled nature of artifacts.

The immutability of the packages is also handy as you pointed out by the hope and a prayer that a tag stays static.

Is there not a global config for rubygems that would specify a list of registries to search for a package instead of having to add them to each project?

Re: The GitHub registry public beta is live

#100

Post by sytse »

no_wizard wrote: post #71

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 very closely what GitHub does with this. 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). I prefer GitLab in every way, but this feature alone might be a goo…

At GitLab we already have a package stage and support Docker, npm, and C packages. More are in the works.

GitLab can also work as a proxy to upstream registers for performance and in the future for security.

Post reply on HN