4 ms·

Entropic: A federated package registry for anything

81 points by dsego 7y ago

rrnewton 7y ago
Hmm, why is this a good thing compared to just using Nix / nix-pkgs to manage JS packages?
- jchw 7y ago
  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.
- ingenieroariel 7y ago
  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?
  - lidHanteyk 7y ago
    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 https://nixos.org/nixpkgs/manual/#node.js-packages
- roryrjb 7y ago
  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.
NetOpWibby 7y ago
Why is this posted here again? Is it usable now?
- tuananh 7y ago
  looks like not much has changed.
drKarl 7y ago
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?
ergl 7y ago
Previous discussion: https://news.ycombinator.com/item?id=20076814 https://news.ycombinator.com/item?id=20076814 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.
- zelly 7y ago
  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.
  - jblwps 7y ago
    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"?
sfobiab 7y ago
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.

81 points by dsego 7y ago

rrnewton 7y ago

Hmm, why is this a good thing compared to just using Nix / nix-pkgs to manage JS packages?

jchw 7y ago
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.
ingenieroariel 7y ago
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?
- lidHanteyk 7y ago
  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 https://nixos.org/nixpkgs/manual/#node.js-packages
roryrjb 7y ago
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.

NetOpWibby 7y ago

Why is this posted here again? Is it usable now?

tuananh 7y ago
looks like not much has changed.

drKarl 7y ago

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?

ergl 7y ago

Previous discussion: https://news.ycombinator.com/item?id=20076814 https://news.ycombinator.com/item?id=20076814 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.

zelly 7y ago
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.
- jblwps 7y ago
  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"?

sfobiab 7y ago

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.