Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Doesn't this bifurcate the namespace of literally every packaging system they are supporting, or are they requiring `@author/`-namespaced package names?

In the livestream he pokes around a github repo, sees it's one author, and decides that what makes it trustworthy? No GPG signing?

The new Actions support (about 50 minutes into the live stream) for auto-publishing from master is pretty sweet. From the very cursory demo, it seems very much like Gitlab's CI pipelines.



GitHub Actions are pretty neat. They were announced last year and I've started using them a few months ago.

You can sign up for the beta here: https://github.com/features/actions

Introduction: https://www.youtube.com/watch?v=_yPml1iTbmM

I'm a little bit anxious because the pricing has not yet been published. Both GitHub Actions and package registry will be free for public repositories but it is not yet known how much it will cost for private repositories after the beta.


They said they expected the package registry to be included in all paid plans. So it's only going to cost you anything if they decide to raise prices for everything across the board, it seems.


Namespaces in general are a mess. I want domain validated namespaces; github.com/example.com/, docker.io/example.com/, @example.com/, facebook.com/example.com, twitter.com/example.com, etc.. Whoever owns the domain owns the validated namespace. I doubt it'll ever happen though since (IMO) namespace squatting makes services look more popular than they are and some sites (ex: GitLab) already allow usernames with dots in them.

As for registries, I didn't like Docker's URLs when I first started, but now I'm convinced it's a good scheme. I can "own" my (domain) namespace by running my own registry. The implementation could have been a bit better though:

* The daemon should allow the user to force the use of a local mirror / cache as a registry. * The daemon should pass full URLs to the registry for requests (https://github.com/docker/distribution/issues/1620).

That way something like Sonatype Nexus could be used as a local caching proxy for all Docker images and could automatically request images from (public) upstream repositories without any additional config.

The new TLDs make perfect identities / namespaces and there are plenty to go around.


> Whoever owns the domain owns the validated namespace.

Owns it for now. It’s a similar problem to TLS certs but with longer term consequences as people don’t generally expect published libraries to expire.


> Doesn't this bifurcate the namespace of literally every packaging system they are supporting

No. Unless you consider the URL the namespace, but it's not.

E.g. I can download the deb "vscode" from https://packages.microsoft.com/repos/vscode

Or I could download that it from a GitHub-user controlled URL, or someone's random website. The name of the package is still "vscode", regardless of what location it was fetched from.


> No. Unless you consider the URL the namespace, but it's not.

It is for docker images. `foo/bar` is implicitly `hub.docker.com/foo/bar`.


True.

I think people are pretty well accustomed to that though. Dockerhub, AWS ECR, Google Cloud, etc.


Yes and no. It affects software that's installed via things like Kubernetes pod definitions. You need to "relocate" images to the correct registry in that case.

This is a sufficient hassle that one of my colleagues maintains an entire tool devoted entirely to this purpose: https://github.com/pivotal/image-relocation


Point being that Github doesn't really add any problem that doesn't exist in spades.


Even with @author, my github username is someone else on npmjs. So installing “@me/module” will either get my module or the other guys depending on sources it would seem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: