
Entropic – A Federated Package Manager for JavaScript - jashkenas
https://twitter.com/i/moments/1135060936216272896
======
tthisk
It is interesting to see the package management approach Deno (Ryan Dahl’s new
project) is taking. It has stated as an explicit goal to make the package
manager part of the same deno runtime. It tries to achieve this by supporting
a native webstandard for modules out of the box. The approach seems to be
partially inspired by the go 1.14 module system.

~~~
Touche
I like this approach too. npm at least, and perhaps other package managers,
are replicating DNS a bit too much for my taste, by providing their own
(centralized) namespace. Why not use the existing namespace that is DNS (which
is decentralized). It's pretty nice to be able to host my packages on my own
servers with my own domain name.

~~~
cjbprime
Usually the motivation is that the federated package names are much longer
than the centralized short package names.

~~~
Boulth
Much longer is, I guess, a matter of taste. For example the package name
"go.uber.org/zap" [0] looks quite short to me.

[0]: [https://godoc.org/go.uber.org/zap](https://godoc.org/go.uber.org/zap)

Not to mention that short names get depleted eventually and one needs to use
longer names then anyway (see npm namespaces).

~~~
andy_ppp
Or even end up with low quality generic defaults for things like routing in
react because someone got the default name of say the routing library.

~~~
mstade
Presumably, if you really want short names, a local hosts like config with
aliased names would do the job just fine. This has the added benefit that
everyone can have their own aliases.

~~~
cjbprime
No, I think the attraction to centralization is not only that it can provide
short names, but that it can provide short names that everyone agrees on the
meaning of.

~~~
WorldMaker
Which is a fascinating echo of the arguments between proponents of AOL
Keywords and DNS.

------
worldsayshi
Here's the actual talk on youtube:
[https://www.youtube.com/watch?v=MO8hZlgK5zc](https://www.youtube.com/watch?v=MO8hZlgK5zc)

------
tyingq
If I visit their website without the www
([http://entropic.dev](http://entropic.dev)), I get some curious JSON:

{"server":"entropic","version":"0.0.1","message":"GCU Fate Amenable To
Change","website":"[https://www.entropic.dev"](https://www.entropic.dev")}

Anyone know the significance of _" GCU Fate Amenable To Change"_? I did Google
it, but that didn't help much.

~~~
misnome
It's a reference to Iain Banks' culture universe - it's the name of one of the
(sentient) ships.

~~~
_Codemonkeyism
[https://theculture.fandom.com/wiki/Contact_Unit](https://theculture.fandom.com/wiki/Contact_Unit)

------
robocat
HN about this 10 days ago:

[https://news.ycombinator.com/item?id=20076814](https://news.ycombinator.com/item?id=20076814)

------
jammi
I don't believe yet another package manager is going to fix anything, more
likely it'll take years to reach maturity, will be riddled with bugs until
then, and have some serious fundamental issues on its own that will be
revealed down the path, _if_ it ever gains popularity.

 _Don 't fix it if it aint broke_ should be a motto for more developers.
Settling for good enough prevents second system effects and retards immaturity
in the form new "trendy" products that over-promise and under-deliver
solutions.

Nothing is perfect, but replacing something from scratch because of some
mostly irrelevant issues that would be better handled by improving the
standard solution usually just causes more issues than it solves.

~~~
na85
Most JavaScript-related threads I see on HN feature at least a handful of
comments from people who will avow that e.g. the npm ecosystem is hot garbage.
Seems to me that it is broke and needs fixed.

~~~
jammi
The main issue with it is that it's too good and successful, therefore it's
too easy to publish whatever crap as your library or its dependencies.

That's not really a fault in the tool managing installation and publishing the
library, its dependencies or managing the repository, providing the auditing
system, script runner frontend and the other things npm does.

You could similarly argue github is hot garbage, because there are so many
crappy projects hosted on it.

~~~
kitd
It is the fault of the tool though if previous versions of a package are
mutable, indeed deletable.

~~~
hobofan
That's a fault of npm - _the registry_'s policies, not of the package manager.
You could do the same with most other popular package managers if you have
control over the registry.

~~~
icebraining
Sounds like you're agreeing with the Entropic people:
[https://twitter.com/bitandbang/status/1134872073896169472](https://twitter.com/bitandbang/status/1134872073896169472)

Their approach is to create a different kind of registries, and inevitably
they need a new client that supports them.

~~~
hobofan
Yes, changing the registry model is key.

I'm not quite convinced by their federated approach though. It feels like its
just spreading out the problems, and not really preventing them from
happening, and in the worst case even creating new ones.

As pointed out in the talk, running a registry becomes expensive once it
becomes popular. So now instead of 1 central registry (which I agree is not a
good idea) needing to fund the hosting, you have maybe 10-100 federated
registries, with each one of them needing to fund the hosting and coming up
with different economic models around it.

I'm also not sure how they would really be able to ensure immutability of
packages in a federated system. A node could simply publish two different
packages with the same name and version number to different parts of the
network. Yes, you can reduce the impact by saving an integrity hash in a
lockfile, but npm already does that today.

------
nameismypw
Instead of using a whole new package manager, couldn't people just use IPFS
through npm?

------
k__
The thing I don't get, is, I'm using Git repos as source for my packages for
years now, why can't everyone do this?

~~~
threeseed
Not everyone tags releases so you're stuck if you need a fixed version of a
dependency.

Or you can tie it to Github and then download a release from their CDN.

~~~
Kovah
You can indeed reference a git repository with a single commit specified, like
described in the npm install docs[1]. Not very user friendly, but it works.

Example:

"dependencies": { "myprivatemodule":
"git+ssh://git@github.com:user/project.git#commit-hash" }

[1]
[https://docs.npm.red/cli/install.html](https://docs.npm.red/cli/install.html)

~~~
k__
This! plus treating every commit as major version and be done with it.

~~~
Cthulhu_
That's a bit too idealistic; in practice, any commit MAY have a bug which
passed quality control. The problem is that it's all down to people's
discipline, it's not an enforced standard.

A package manager where every release has to be reviewed, tested and approved
before they become generally available would be a pretty interesting case, I
know bigger companies who are reluctant to upgrade because of known bugs in
the past would be willing to pay for something like that.

------
mmcclure
There's quite a bit of hand wringing about whether or not this is good or bad
as if there's no universe in which Entropic and NPM simply co-exist.
Options/competition is good for tools like this, why not encourage it?

On the "new registries" note, though, and I might be alone on this one, I'm
honestly the most interested in Github's package registry. No, it's not
decentralized, yes it's still owned by a big company, but I'm personally fine
with the tradeoffs there. It's kind of reassuring that the entirety of
Github's revenue is a rounding error for Microsoft, so I at least don't think
there's the same concern around the VC backing of NPM.

------
boblebricoleur
As "life finds a way", I believe packages will find a way too.

If npm stops being the go-to solution, another one will take its place,
naturaly adopted by the community, following the path of least resistance.
Centralized or not. It does not really matter. What does matter is the code
that's being downloaded. Modules dependencies management is an old problem,
countless of tools have tackled.

Is the node and front projects architectures that dependent on npm ? It's a
little coupled but not that coupled ? The dependency management still require
a little brain power from dev teams, or does it really fully relie on the
package managers ?

~~~
el_programmador
Forgive me for being a contrarian but I see nothing more than yet another
Stallmanist rant in this?

Ceej and company are trying to portray NPM as the villain here, but is the
entire JS ecosystem's burden their's to carry? They keep whining that Roald
Dahl is miserable and all despite inventing Node and why the NPM founder is so
rich with VC money, etc. According to me, therein lies their hypocracy:

On one hand, you declare your altruism and how you care about commons and not
money but on the other hand, you try to imply guilt on those who try to earn
money out of JS ecosystem! How is this fair? You do your job and let them do
theirs, I don't see how NPM is made the villain here?

~~~
boblebricoleur
My point was : node is just a web server and npm just a package manager. There
was countless before, there will be countless after, we will continue to code
with or without. I have worked with a few technologies and in a few industries
and package management is always complicated. The nature of the package
management tools are not that important.

The passion that this kind of topic seems to unleash looks like the
consequence of a terrible fear a loosing control over an irreplaceable tool.
But no tool is irreplaceable : if you can't/don't want to(for political
reasons) use node, npm or even javascript just use something else.

That just it. I have no opinion about who makes money from what. At least, not
in this thread.

~~~
neurotrace
Minor note: it's not accurate to say that node is a web server. Web servers
are frequently built with node but node is also used for CLIs, graphical
applications, parsers, compilers, etc.

~~~
boblebricoleur
I see. Thanks for the clarification

------
pavlov
Feels like there's a piece of the story missing:

"There was one individual who planned though and didn’t give their viral
software away for free."

Who was that?

~~~
worldsayshi
Isaac Z. Schlueter, the original creator of npm? I thought it was clear from
the context but perhaps I'm missing something.

------
rashthedude
What about Yarn?

~~~
bryanlarsen
Yarn currently uses the npm registry.

------
aepiepaey
One of the slides says:

> they hired a CEO who made some, um, _interesting_ moves

What is this referring to?

~~~
steveklabnik
Previously,
[https://www.theregister.co.uk/2019/04/01/npm_layoff_staff/](https://www.theregister.co.uk/2019/04/01/npm_layoff_staff/)

Yesterday,
[https://www.theregister.co.uk/2019/06/14/npm_union_busting_c...](https://www.theregister.co.uk/2019/06/14/npm_union_busting_claims/)

------
kostarelo
I am wondering, without having much knowledge about it, could a system like
Ubuntu's package manager & registry (or any other Linux's distro) be suitable
for JS?

~~~
eeZah7Ux
Of course. APT is used to install JS libraries already but people prefer the
npm because it gives people enough freedom [to make the ecosystem a complete
mess].

~~~
kostarelo
Can you please explain how APT limits freedom?

~~~
roryrjb
I take it to mean that with npm there is a very low barrier for entry. I mean
it's not difficult to actually host an apt repo on your own server or on S3,
but there's still more you need to know to get to that stage. I personally
think that using something like apt for Node.js dependencies is a very good
idea. I work with Node at work and on the side, and my/our usual stack is
either Debian or Ubuntu. Even when Docker gets involved it's usually a Debian
or Debian based image. [Edit: phrasing]

~~~
kostarelo
I am trying to understand why we make NPM such a big deal (and suddenly have
all these projects born to solve the NPM problem) when people have solve the
issue of a package repository already. C j Silverio's point (JSConf's talk
[1]) was that is NPM's scale that makes it hard.

Refs:

1:
[https://www.youtube.com/watch?v=MO8hZlgK5zc](https://www.youtube.com/watch?v=MO8hZlgK5zc)

~~~
steveklabnik
To put some perspective on this, comparing Debian to npm:

Number of packages:

Debian has 172,000 packages for the most popular architecture, amd64. i386 has
24,000 packages. The rest have less than 500 each.

npm recently broke a million packages.

Download counts:

I couldn't find numbers for Debian. npm served 11.2 billion downloads last
week.

(Debian numbers retrieved by
[https://popcon.debian.org/](https://popcon.debian.org/), npm numbers from
[https://medium.com/npm-inc/npm-weekly-200-dont-miss-
today-s-...](https://medium.com/npm-inc/npm-weekly-200-dont-miss-today-s-tech-
talk-1-million-packages-plus-learn-how-npm-s-security-f75f9882aebe) and
[https://api.npmjs.org/downloads/point/last-
week](https://api.npmjs.org/downloads/point/last-week)

~~~
regularfry
Debian also has a repository model which allows the packages to be served by a
static file server, because the dependency resolution is entirely client-side.
Npm doesn't.

~~~
steveklabnik
Hm, as far as I know, resolution is also entirely client-side for npm. Do you
have any links about this?

