[erlang-questions] Erlang package manager

Loïc Hoguin essen@REDACTED
Sat Jan 3 19:12:09 CET 2015

On 01/03/2015 03:54 PM, Björn-Egil Dahlberg wrote:
> 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. =)

I'm mostly fine with this, but: please make sure the package manager 
client is very much like erlc and does not attempt to start a huge VM to 
do 2 HTTP queries. Escripts, erl -s/-eval and the likes are not good for 
short-lived command line programs.

I'm concerned with "let it upgrade itself once downloaded". It sounds 
like the package manager has to handle not only OTP/library 
applications, but also executables. Scope needs to be clarified.

> 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.

Packages in the index should only be Erlang applications, yes. But the 
package manager client cares little what the packages contain. All it 
needs at most is a list of files. It doesn't need to know what the files 
are. Don't prevent people to make private repositories that work for 
them if they want to.

> 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.

Good job mentioning explosions and Gearbox in the same context.

Namespace for things that try to say "packages" or "manager" or 
"repositories" is fairly crowded, so my vote goes to "tomato". But if 
you want to keep the name on topic then I vote for "perl", Packages for ERL.

Loïc Hoguin

More information about the erlang-questions mailing list