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

61–70 of 137 posts

Re: The GitHub registry public beta is live

#61

Post by hprotagonist »

OJFord wrote: post #11
hprotagonist wrote: post #6

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?

Some function of popularity on the platform and ease of implementation, I'm sure. And, I suspect (from python's noteworthy absence), degree to which the language's users were already (mis)using GitHub releases (or sites) for this purpose.

yes but i

  pip install git+https://github.com...
very often!

Re: The GitHub registry public beta is live

#62

Post by chrisseaton »

danShumway wrote: post #59
chrisseaton wrote: post #56

Earlier quoted context omitted.

It's the file layout, for just one thing. You can't just point Maven (or many package managers) at a simple HTTP server without the correct layout. If you could... they wouldn't have built this.

Can't you? http://repo.maven.apache.org/maven2/ looks a lot to me like a simple HTTP server. I'll take your word on it though. I don't know much about how Java package management works, and like you said, I assume the Github team wouldn't waste their time building something that wasn't necessary. I guess if nothing else it would be a pain in the neck to have to know in advance how release files had to be laid out.

> ...without the correct layout

How are you going to recreate that directory structure with GitHub releases? You can't even have any custom directories - they're just release-name/file-name.

I mean just try recreating it yourself and see how far you get.

You could try use GitHub pages instead, but GitHub very actively pester you if it even looks like you're distributing binaries there.

Re: The GitHub registry public beta is live

#63

Post by eridius »

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…

That would be cool, though I'd prefer an approach where the channels maintain a database of the pname/version combo for every package in the channel, and an API where you can query to find out what version of the channel contained a given pname/version combo for a given attribute path. Then you can just download the tarball for that version, no git needed anywhere.

In theory, that database could also just be included in the channel so it could be queried locally, but I don't know how large it would end up being.

Re: The GitHub registry public beta is live

#64

Post by orf »

craigds wrote: post #54
ageofwant wrote: post #48

Earlier quoted context omitted.

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

git urls are tricky to use with many tools (like pip-compile) though. At best they're slow, since things like "what's the latest version?" require downloading the repo. We forked some things into a private DevPI instance at present for that reason (well, also for latency)

Pipenv locks the VCS dependency to the commit, making pulling very fast.

Re: The GitHub registry public beta is live

#67

Post by jolmg »

eridius wrote: post #63
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…

That would be cool, though I'd prefer an approach where the channels maintain a database of the pname/version combo for every package in the channel, and an API where you can query to find out what version of the channel contained a given pname/version combo for a given attribute path. Then you can just download the tarball for that version, no git needed anywhere. In theory, that database could also just be included…

Honestly, I think I like doing it with git more. If you maintain such a "database", you'd have to explicitly state version info for the dependencies of every package. That's done automatically with git. For a particular version of a package, the versions of the dependencies it's compatible with are those that are present in the same commits.

Also, to maintain package building scripts in a database outside of git would require either making 1 script per package that builds every version of that package ever. That sounds inconceivably hard. Another option is to have separate scripts per version, which sounds redundant. Another option is for newer scripts to import code from previous versions' and override parts, which sounds convoluted. If you use git, the script only has to worry about the current version. Not forgetting how to build previous versions would be automatically handled by git.

Re-reading your comment thought, I think you're talking about pre-built packages. If that's the case, then I think I agree. I'm talking about the repo containing the scripts for building such packages.

Re: The GitHub registry public beta is live

#68

Post by cranky_coder »

jonny383 wrote: post #66

Honestly, GitHub has been going down hill for about 18 months now. It all started with the ":D Set status" feature. I give it another two years before Microsoft has officially turned GitHub into a 2021 version of Skype

I’m confused, is this an example of one of those “:D Set status features”? It seems useful to me...

Re: The GitHub registry public beta is live

#69

Post by jonny383 »

cranky_coder wrote: post #68
jonny383 wrote: post #66

Honestly, GitHub has been going down hill for about 18 months now. It all started with the ":D Set status" feature. I give it another two years before Microsoft has officially turned GitHub into a 2021 version of Skype

I’m confused, is this an example of one of those “:D Set status features”? It seems useful to me...

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

Re: The GitHub registry public beta is live

#70

Post by dstaley »

jonny383 wrote: post #69
cranky_coder wrote: post #68

Earlier quoted context omitted.

I’m confused, is this an example of one of those “:D Set status features”? It seems useful to me...

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.
Post reply on HN