[erlang-questions] Erlang package manager

[zxq9]

On 2014年12月16日 火曜日 15:56:22 Eric Pailleau wrote:
> I forgot to say that Erlang packages may need Non Erlang application, like
> Postgresql, or Varnish or (fill blanks). Debian Meta package allow this,
> for instance. This could not be achieved with a specific Erlang packager.

There are no Erlang packages or builds that require Postgres. Some C 
interfaces may require Postgres headers to build (and these are not "Erlang 
packages" in the strict sense), but most Erlang systems that have anything at 
all to do with something like Postgres need to be given the address of a 
servicing port with which to connect.

This is not an Erlang build issue. At all. Ever.

The way this is handled is through OS distributions -- and if the decision 
were made to include this sort of "build" support (or rather, not "dep 
resolution" but "adjacent service provision") then the package manager would 
wind up becoming its own OS distro in short order, and from there wind up 
trying to be OpenStack. And it can't ever be that. Not even anything remotely 
close to that.

The only thing even sort of close would be for Erlang to pick a single distro 
of a single OS on a single platform and settle on that as the sole reference 
implementation forever and ever, amen, and pour time into maintaining that 
(blessed) distro's Erlang subsection of packages through its package manager. 
This, actually, is workable from a technical point of view -- but is 
guaranteed to not be socially workable, even if it were done in the Belly of 
Some Beast (neither MS nor IBM has been able to pull this off, and they own 
their entire stack) -- actually, I imagine the annoyance of keeping up with 
this sort of thing is why Erlang was spun out of Ericsson in the first place.

And that leaves us back at the original problem, which has been demonstrated 
to be twofold:

1- Define an ecosystem within which code can be grown and known to survive with 
a minimum of wasted developer effort.
2- Set clear limits of that ecosystem.

The ecosystem definition is really more important than any particular 
implementation of a tool within it -- but that gets into standards, and who 
follows those without a reference implementation anyway? (And who spends time 
writing *and* maintaining new implementations when the reference platform 
already works well? We want to do more interesting things with Erlang than 
write more Erlang, I imagine...) It has to be complete enough to cover the 
problem space so that something can be implemented in the first place -- but 
absolutely can't go so far that it suffers from second-system-syndrome.

I've got plenty of ideas what the above statements should mean, but that's not 
the point of this message. My purpose is to point out straight away that this 
entire idea will be DOA if we let the Good Idea Fairy serve up a big dream 
steak smothered in hope peppers with a side of good intentions and a community 
love salad before even a line of code has been written.

-Craig