<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-01-03 19:12 GMT+01:00 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/03/2015 03:54 PM, Björn-Egil Dahlberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. The Package Manager client should (will/must) be written completely<br>
in Erlang. There are many reasons for this. For instance, it is easier<br>
to maintain an application written in a language we have some<br>
familiarity with. It is a nicer fit. We can have the client the client<br>
in the bootstrap and let it upgrade itself once downloaded. I don't<br>
think OTP can really be satisfied with anything else than a PM written<br>
it in Erlang. =)<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>Well, I know this is a pet peeve for you =)</div><div>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.</div><div><br></div><div>This is however not in the scope of the package manager.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.</blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Scope it down. For starters the Package Manager should only handle<br>
Erlang applications. Things like Erl_Interface and JInterface are the<br>
odd one outs in the lib directory today and they don't really fit here.<br>
At least not how I envision it. I'm sure we could jury-rig something but<br>
we should not start there. This also mean that we should *not* handle OS<br>
dev-libs in our package-manager. We can have a specialized description<br>
field for such things, telling the developer he needs to install them<br>
prior to installing an Erlang application but we should not handle it<br>
beyond that.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div><br></div><div>True, but let's limit this to Erlang applications for starters. Make sure we can extend stuff and then take it from there.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I hesitate to discuss the naming of this thing in fear of something<br>
exploding. But, I will throw my hat into the race .. Gear (client) and<br>
Gearbox (server). Gear - Erlang Application Repositories. With commands<br>
like "gear up .." for upgrading packages and "gear down" for downgrading<br>
them.<br>
</blockquote>
<br></span>
Good job mentioning explosions and Gearbox in the same context.<br>
<br>
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.</blockquote><div><br></div><div>*boom*</div><div><br></div><div>// Björn-Egil</div></div></div></div>