<div dir="ltr">On Mon, Feb 12, 2018 at 11:36 PM Vlad Dumitrescu <<a href="mailto:vladdu55@gmail.com">vladdu55@gmail.com</a>> wrote:<br><div class="gmail_quote"><div><br></div><div>[...Checksums...]</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Am I misunderstanding something?</div><div><br></div></div></div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">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:</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* Essentially, a package manager should work like git does in the underlying layer.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* A package rename does not change its checksum. Rebar[0] doesn't seem to be able to understand this.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">* 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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">That said:</div><div class="gmail_quote"><br></div><div class="gmail_quote">As Tom Santero mentioned already, any new package manager has to explain why it is different and/or better than Rebar3/<a href="http://hex.pm/erlang.mk">hex.pm/erlang.mk</a>. 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?"</div><div class="gmail_quote"><br></div><div class="gmail_quote">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 <a href="http://erlang.mk">erlang.mk</a> 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).</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">[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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">[1] <a href="https://www.cl.cam.ac.uk/~hm519/ocaml2016.pdf">https://www.cl.cam.ac.uk/~hm519/ocaml2016.pdf</a></div><br></div>