[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services

[Jesper Louis Andersen]

On Mon, Feb 12, 2018 at 11:36 PM Vlad Dumitrescu <vladdu55@REDACTED> wrote:

[...Checksums...]

Am I misunderstanding something?
>
>
I don't think you are misunderstanding anything. To a certain extent, our
advocacy is about making a content addressable store be the bottom layer in
the package manager, and then have a naming layer on top of this:

* Cryptographic checksums have integrity. I don't have to trust the package
repository and thus the repository can be mirrored. They are also way
easier to sign.

* Essentially, a package manager should work like git does in the
underlying layer.

* A package rename does not change its checksum. Rebar[0] doesn't seem to
be able to understand this.

* A package cannot be removed by checksum. It can be removed by name, but
if a repository keeps the checksum alive, it is for all senses and purposes
accessible.

* The checksums are the identifier and the name is simply a human-readable
attachment. This is important since it avoids a lot of the social
interactions which occur on top of packages and decouples it from
technicality to some extent.

* You can easily create name spaces on top. This is highly important as we
can see in many cases: You may want company-overrides, you might develop a
package in your own namespace as a fork, you might prepare to take over an
official package on the side and only flip the name at a later stage. And
you can easily use a name such as racoon twice if need be.

* The scheme amends itself to something like Conex[1], in which you don't
have to trust the package repository. Conex also makes the distinction
between package authors and repository janitors. The latter should have the
ability to override certain aspects of packages (for instance version
compability rules) without altering the underlying source code (such that
it is still verifiable).

That said:

As Tom Santero mentioned already, any new package manager has to explain
why it is different and/or better than Rebar3/hex.pm/erlang.mk. And in
hindsightm, an announcement, name not included, ought to make this point
and hammer it in. In short "why do I want to use your package manager over
the existing ones?"

In my experience, it is far better if you take existing systems and
gradually refactor them. Or you work with them rather than against them.
Rebar3 screams to the world that it wants to be modular to a greater
extent. It is trying to solve 3-4 problems at the same time, which is
usually a recipe for long-term disaster. As you can't replace individual
parts, development will slow over time. Hex.pm wants to the be little
sister of npm. This is not a bad idea per se as an initial design. Yet,
that doesn't move us toward a better package manager ecosystem. Finally
erlang.mk tries to be too much at once, even though I think it is the best
manager out there by far from an engineering perspective (it helps that it
has had few authors so their vision is far more aligned).

So the right course of action is to first make the case for a couple of
refactorings in existing projects. Then, when those refactorings are done,
you can start working on the improvements. But getting people aligned on
your vision is important here. Otherwise, other programmers will be
destroying your work at a much greater pace than you can fix it.

[0] Rebar has had many iterations, and started in a different spot, so it
is by no means a critique. Different designs lead to different solutions.

[1] https://www.cl.cam.ac.uk/~hm519/ocaml2016.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180213/9fd6a5ed/attachment.htm>