Entropic: A federated package registry for anything(github.com)
github.com
Entropic: A federated package registry for anything
https://github.com/entropic-dev/entropic
12 comments
IMO the git/github scenario was the least harmful because git is actually decentralized. If github goes down or turns bad, the exodus to a new platform would happen faster than it happened on sourceforge. The SaaS should be walking on eggshells by design—that can only happen with real decentralization at the protocol layer, like git but unlike smtp or xmpp. That way we are just freeloading off whatever cloud company wants to take us before we jump ship.
What about guaranteed software freedom for the server via the AGPL (or any similar license that exists)? Granted, that would cover the actual server-side components and not the actual protocol itself.
Depending on how the Oracle V. Google case goes (i.e. if Google successfully appeals to the Supreme court, or if the Appellate Court's ruling stands), maybe we could get something like "The AGPL for protocols"?
Depending on how the Oracle V. Google case goes (i.e. if Google successfully appeals to the Supreme court, or if the Appellate Court's ruling stands), maybe we could get something like "The AGPL for protocols"?
For anything? Does it support maven coordinates to use with maven/ gradle? Does it support docker images as a docker registry? Can it mirror other repos like maven central?
Hmm, why is this a good thing compared to just using Nix / nix-pkgs to manage JS packages?
Similarly in my experience apt/deb packaging should be considered for this. There's already node packages in Debian/Ubuntu, to look at examples, it's well documented, tried and tested, they can be signed, and it's straightforward to setup a repo which is completely static, so can be put in S3 or any static server, there's apt-transport-tor, for working over tor, there's apt-transport-s3 for working with private S3 buckets. OK there's some versioning quirks (I've used both launchpad and reprepro) such as tying it to a release version (buster, xenial, bionic, etc..) and having only one version of a package available per release in the case of reprepro, but in my experience it was easy to setup and maintain. Also the penetration of the format means you can consume it, in one form or another on Linux, WSL, ChromeOS, Docker, K8S, etc.
I tried doing this for golang with dep2nix and vgo2nix and it is quite hard, but I succeeded.
I tried with yarn2nix and quickly decided to just use regular nom install every time.
Can you share your experience?
I tried with yarn2nix and quickly decided to just use regular nom install every time.
Can you share your experience?
nixpkgs top-level only accepts full applications, not libraries, but there is a documented procedure for adding applications to nixpkgs: https://nixos.org/nixpkgs/manual/#node.js-packages
Wait, is that common? I’ve not seen anyone doing that before. A cursory search shows a tool that takes a yarn.lock file and turns it into a Nix expression, but that’s all I can see.
Looks like the project has gone quiet pretty quickly, at least in comparison to the amount of Twitter traffic from some of the people who left npm to start it.
Last PR was closed almost a month ago, same pattern with the Discourse. Issues are largely unanswered.
Last PR was closed almost a month ago, same pattern with the Discourse. Issues are largely unanswered.
The idea of a federated package registry is good: it tries to avoid centralization and control of a language ecosystem by a private company (like it happened with NPM).
However, I think it can easily be gamed, the same way Git was gamed by GitHub. I do wonder what prevents any of the big companies, for example, Microsoft through Github, to host an instance of Entropic, and adding too-good-to-be-true features on top. These could be automatic vulnerability alerts, detailed metrics, integration with code completion services, but only if you use their instance, and could serve to convince anyone to host mainly on Github’s instance. Then they roll their own CLI that supports Github-only features, and then they close API access to third party clients. The Apache 2 license would allow all of this, without problems.
This has happened before with XMPP (Google Talk, Facebook Chat), IRC (Slack, Discord) and SMTP (Gmail). I think we’ll need more than federated protocols to solve the problem of VC-backed companies, but at least this is a start.