[erlang-questions] Erlang package manager
Tue Dec 16 17:38:07 CET 2014
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.
More information about the erlang-questions