[erlang-questions] Erlang package manager

[Björn-Egil Dahlberg]

2015-01-03 19:12 GMT+01:00 Loïc Hoguin <essen@REDACTED>:

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

Well, I know this is a pet peeve for you =)
I don't think we should let the startup time limit our design choice here.
I believe the startup time is tightly coupled to loading all the modules
and then letting the beam-loader transform it. This could probably be
improved but I don't know how easily. Ideally we would like heat up a
running beam with all the modules loaded and then dump the memory to disk
.. appended to some binary, e.g. beam. That should shave off some startup
time.

This is however not in the scope of the package manager.


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



I'm getting ahead om myself here. Think of it as having a precompiled
package manager client application in the bootstrap, like the erlang
compiler. It is an older version, if you want to have a newer version it
can upgrade itself just like any other application. It is nothing special
about it.



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



True, but let's limit this to Erlang applications for starters. Make sure
we can extend stuff and then take it from there.



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


*boom*

// Björn-Egil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20150103/7585bb1c/attachment.htm>