Live data from Hacker News

The GitHub registry public beta is live

help.github.com

41–50 of 137 posts

Re: The GitHub registry public beta is live

#41

There's no immediate mention of this on the site, but -- why did they select the package formats that they did? I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?

> There's no immediate mention of this on the site, but -- why did they select the package formats that they did?

Don't know but the formats do not seem to match the Azure DevOps package feeds formats (some overlap of course but some missing in one, some missing in the other) so it's not from shared code.

Re: The GitHub registry public beta is live

#42

Earlier quoted context omitted.

In my experience, using git as a dependency source for NPM (including yarn) or Ruby never worked well. It works for a simple case, but it's usually much slower, has issues around managing credentials for private repos, and doesn't have a nice way to publish built files.

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.

Re: The GitHub registry public beta is live

#43
post #29

> is a software package hosting service, similar to npmjs.org, rubygems.org, or hub.docker.com, that allows you to host your packages and code in one place. You can host software packages privately or publicly and use them as dependencies in your projects. I am... really confused by this. Isn't this just Github? Github is a hosting service that allows you to host your packages and code in one place. It has testing an…

It may seem less useful for interpreted languages, like JS, where the code is the artifact. For compiled languages, having a separate place to store official artifacts is much more important.

Compiled and interpreted are not mutually exclusive either. In particular in the JS world it’s very common to transpile from modern JS or TypeScript to lowest common denominator JS.

Re: The GitHub registry public beta is live

#44
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.

Re: The GitHub registry public beta is live

#45

There's no immediate mention of this on the site, but -- why did they select the package formats that they did? I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?

Perhaps because pip already supports git repos:

    git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit

Re: The GitHub registry public beta is live

#46

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 Firefox or Chrome from a decade ago as easily as I can install the latest versions.

I wonder if it'd be too crazy to add git-awareness to the Nix utils. Like tell nix to install version X of some package, so in the nixpkgs repo it would check the history of the corresponding file to find the commit where it last was that version, checkout that commit, build the package and its dependencies, and then return to the branch it was at.

Re: The GitHub registry public beta is live

#47
post #39

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

At least for Ruby, it was easy to pin a specific commit SHA in the Gemfile to guarantee immutability.

That does not guarantee it exists at the source repo though. You can’t create different content at that same hash, but you can rewrite history or delete the branch of that hash entirely and it will eventually be GCed away.

Re: The GitHub registry public beta is live

#48
post #26

Still no python support :(

A bit disappointing yes, but pip has had support for git repo's for many years. In requirements.txt:

    git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit
So perhaps that's why, still would like to have a github hosted devpi

Re: The GitHub registry public beta is live

#50

There's no immediate mention of this on the site, but -- why did they select the package formats that they did? I'd love to be able to host wheels for my python projects, or {rpm, deb, flatpack, etc...} for effectively arbitrary code. Is that in the works?

Perhaps because pip already supports git repos: git+ssh://git@bitbucket.org/foo/bar.git@fixit/atemp69#egg=hotshit

And it also works from requirements.txt
Post reply on HN