[erlang-questions] more thoughts about package/dependency management

[Tim Watson]

On 30 May 2012, at 15:40, Tuncer Ayaz wrote:

> On Tue, May 29, 2012 at 12:11 AM, Tim Watson wrote:
>> http://hyperthunk.wordpress.com/2012/05/28/does-erlangotp-need-a-new-package-management-solution/
>> 
>> This is a summary of the Erlware-Questions discussions - hopefully
>> I've been true to what was said on the list, but if I've
>> misrepresented anyone's opinion then I apologise and hope that
>> you'll put it down to my 'special' short/medium term memory. :)
>> 
>> Comments/Feedback welcome.
> 
> Thanks Tim for the summary. I mostly agree with you and Garrett and
> think that distros and Hackage are a good source for inspiration.
> 

I agree in principle, and Garrett raised some good points.

> A few important points:
> 
> - No need for storing (meta)data in a real vcs:

Ok so Eric and I were trying to avoid the need for hosting, making this completely free and community oriented. You want to go down some hosting route, that's fair enough, but who's going to provide the infrastructure? It worries me that this will put people off using the system and we'll end up getting nowhere.

Apart from that I'm fine with the idea though.

>  + The index needs to be aware of all versions.

+1

>  + The versions should be kept as (archive) files in directories.

Well that's fine if it's hosted, as the search can be very simple and the download just goes direct to the packaging using FTP or whatever. For 'non hosted' - read hosted on github or some such - then this was more of a sticking point, so I guess we need to iron out exactly *how* this stuff can/will be hosted before making that kind of decision about the repository layout.

>  + The index can be modified to add or remove entries. Replace
>    doesn't seem like a good idea. It can be implemented, if needed.

Snapshot builds are a PITA, but some shops depend on them for CI etc.

>  + Branches or merging shouldn't be required.
> - We should consider leveraging existing ftp mirror networks like
>  distros and texlive do. For both the files and index.

How will this work in practice?

> - We should look at dpkg (apt) and rpm (yum) for index and signature
>  inspiration.
> - Sandboxing should be part of the initial design.

+1

> - It has be trivial to get the tool(s) either as part of Erlang/OTP or
>  with a simple download like rebar.
> - It should not require any fragile dependency as you need working
>  tools to get packages.
> - The website can be made central, but should be avoided if possible.

What does this mean? This is sounding more and more like a system that someone has to build and maintain. I'm *absolutely* in favour of doing that, but someone is going to stump up the money for it.

> - Hayoo like search would be nice to have in a 2nd step.
> 

Again, this is *great* idea, but someone, somewhere, covers the cost of hackage/hayoo - the same applies here.

> Do we need an infinite set of version or should it be limited like
> distros do with the various channels and a pool of versions referred
> to in the current indices?