[erlang-questions] Erlang package manager

[Tuncer Ayaz]

On Sat, Jan 3, 2015 at 3:54 PM, Bjorn-Egil Dahlberg wrote:
> Hi everyone!
>
> I would like to address some of the questions and comments in this
> discussion. I will be brief and get into more details once I get
> back to Stockholm.
>
> 1. The Package Manager client should (will/must) be written
> completely in Erlang. There are many reasons for this. For instance,
> it is easier to maintain an application written in a language we
> have some familiarity with. It is a nicer fit. We can have the
> client the client in the bootstrap and let it upgrade itself once
> downloaded. I don't think OTP can really be satisfied with anything
> else than a PM written it in Erlang. =)

+1

> 2. Scope it down. For starters the Package Manager should only
> handle Erlang applications. Things like Erl_Interface and JInterface
> are the odd one outs in the lib directory today and they don't
> really fit here. At least not how I envision it. I'm sure we could
> jury-rig something but we should not start there. This also mean
> that we should *not* handle OS dev-libs in our package-manager. We
> can have a specialized description field for such things, telling
> the developer he needs to install them prior to installing an Erlang
> application but we should not handle it beyond that.

I mostly agree, but I also want to stress that we have to figure out
and implement extensions to .ez and .app (embedded in .ez)
infrastructure, and maybe prepend or append (probably easier) metadata
in archives.

As we use a VM anyway, I don't see a good reason not to support
multi-arch fat archives which contain .beam, .so, .dll,
<other_resources> for ease of deployment.

Also, please consider my remarks in:
http://erlang.org/pipermail/erlang-questions/2014-December/082132.html

If something's not clear in that post, please ask for clarification.
I've tried to list things which - these days - are forgotten or
mis-implemented in most non-CPAN/non-CTAN managers.

> 3. Protocols first. I saw someone mentioning this already and it
> made me so happy. Protocols first is perhaps a misnomer but it is
> important anyway. We have several languages that runs ontop of beam
> or Erlang. Elixir has its own package manger Hex (client) and Hexweb
> (server) and I think it is a good thing if we use compatible
> protocols. Http and restful protocols is all the rage and I don't
> any reason to sidestep that. My vision here is a common protocol bus
> and the client can query any server for Erlang applications, i.e.
> Hex can query an Erlang Application provider for updates and install
> them. I think this only affect us (Erlang) by pressuring us to
> formalize our rest protocols / api .. but that is a good thing.

As long as we're not held back by limitations of existing protocols,
and are free to improve/extend, sure, it's a good approach.

> I hesitate to discuss the naming of this thing in fear of something
> exploding. But, I will throw my hat into the race .. Gear (client)
> and Gearbox (server). Gear - Erlang Application Repositories. With
> commands like "gear up .." for upgrading packages and "gear down"
> for downgrading them.

Why not integrate it as subcommands in 'erl', as we already have a
distinctive 3-letter CLI slot occupied in $PATH? Seriously.