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

71–80 of 137 posts

Re: The GitHub registry public beta is live

#71

Post by no_wizard »

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 good enough reason to switch. It would make releases just so darn easy. The only thing I hope (which is not made clear) is that the stipulation that you can't easily delete a package on the registry (According to the link, its only for GDPR requests and legal reasons) is something that, for instance, an Enterprise account wouldn't have. I already have our purchasing team looking into it, thats how serious this is.

If the API for hitting these packages is any good, its gonna be so hard to resist.

I really hope GitLab has a good response to this.

To wit, since GitLab is custom hosted, I wonder how hard it would be to add this into the CE edition....

With all that said, I wonder what the hidden limits will be. Imagine if instead of NPM maintaing all of its servers, it was just a thin database that had better routing to github releases? Would that fall afoul with GitHub?

I mean, whats the point of maintaining your own distribution server when GitHub can front all the hosting costs and all you have to do is map the name of a package to its Github Package Release URL. I could see NPM, PyPI et. al. just doing that, instead of having their own servers. Maybe its a good idea to run additional cache nodes, but GitHub being the main place where release code lives for you package index would cut the bills significantly no?

Re: The GitHub registry public beta is live

#72

Post by eridius »

jolmg wrote: post #67
eridius wrote: post #63

Earlier quoted context omitted.

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

The default way to consume nixpkgs is through channels which today does not involve git. And a nixpkgs git checkout is over 1GB (my .git dir is currently sitting at 1.4GB on this machine). So that's not great.

> If you maintain such a "database", you'd have to explicitly state version info for the dependencies of every package.

I don't know what you mean. If I say "I want git v2.10.0" I don't care about dependencies; whatever nixpkgs tarball I download that has that will have the dependencies too. There will be a whole range of nixpkgs tarballs that contain the requested git version of course, but with such a database I could also say "find me a channel tarball that contains both git v2.10.0 and some-dependency v7.23" if I want that particular combination (assuming the two coexisted in the same nixpkgs at some point).

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

This is true of downloading a nixpkgs channel tarball too.

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

I don't know what you mean by this either.

> Re-reading your comment thought, I think you're talking about pre-built packages.

No I'm not.

What I'm talking about is just any time hydra builds a channel, it can run a script that collects the pname/version combination for every derivation in nixpkgs (or at least, every searchable derivation; we probably don't need to collect this from all the invisible helper derivations). This can then be appended to a database from the previous version, such that we end up with this information for every single tarball.

In fact, this is pretty much exactly what you'd do for git, except you'd build it incrementally rather than running a script that processes the entire git history from scratch (which is pretty much building it incrementally for every commit).

Re: The GitHub registry public beta is live

#73

Post by tacticus »

jayflux wrote: post #65
thefounder wrote: post #10

I like Go more. The git/hg/svn/bz repository is the "package". No custom (and central) "registry"

There was a Go dependency that got deleted (repo removed) and screwed everyone else’s project up, so I’m not sure this is perfect either.

Which won't stop it happening with a package manager either.

Even immutable repos are going to have fun with DMCAs.

Re: The GitHub registry public beta is live

#74

Post by itslennysfault »

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…

This is a feature Azure DevOps (formerly Visual Studio Team Services) has had for at least 3 years now. Their repositories Maven, Gradle, Pip, and NuGet in addition to NPM. I'm always surprised more people don't use it. It's a full featured ticket system, git (PRs / etc), package feeds, and ci/cd in one neat package.

Re: The GitHub registry public beta is live

#76

Post by bbatha »

Pxl_Buzzard wrote: post #13
danShumway wrote: post #9

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

This appears to be a move to meet package managers halfway. Yes, tools like npm and go have great integration with git repositories, but others like NuGet still require a hosting source. Long-term, you could imagine package managers forgoing their own hosting services in favor of letting GitHub be the primary host who takes on the issues of bandwidth, availability, access controls, etc. It's another vector for GitHub…

It’s also good for githubs economics to be able offload data from git itself to easily mirrored versioned tarballs. It’s much more cost effective than mirroring constantly changing master branches or worse whole git repos for clones.

Re: The GitHub registry public beta is live

#77

Post by no_wizard »

itslennysfault wrote: post #74
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…

This is a feature Azure DevOps (formerly Visual Studio Team Services) has had for at least 3 years now. Their repositories Maven, Gradle, Pip, and NuGet in addition to NPM. I'm always surprised more people don't use it. It's a full featured ticket system, git (PRs / etc), package feeds, and ci/cd in one neat package.

I did not know that. Though, we aren't on Azure for anything at all (AWS for some HIPAA stuff, Google Cloud or our own proxmox cluser for the rest).

I know Azure Pipelines is becoming the sort of defacto automated CD/CI pipeline though (used to be Travis for so long) and I've heard nothing but good things about that. Might have to take a look.

Re: The GitHub registry public beta is live

#78

Post by quickthrower2 »

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?

That is an interesting idea, playing on people's confusion as to where to install from. And someone is going to put the super terse `npm i -g mytool` on their README.md page (because it's all about the easy installs isn't it!) and forget to say "change your registry to github" and boom!

Re: The GitHub registry public beta is live

#79

Post by takeda »

alexbecker wrote: post #57
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?

Running a python package registry has some unique challenges, so it makes sense not to start with it (I run such a registry: https://pydist.com ). For example, Python has a distinction between distributions (the actual file downloaded, e.g. a tarfile or a manylinux1 wheel) and versions that doesn't exist in most other languages.

All of these concerns are handled on client side, in the end all python needs is an http server, it can be actually hosted on S3.
Post reply on HN