[erlang-questions] Building, Packaging and Installing

[Tim Watson]

On 02/05/2012 21:13, Ciprian Dorin Craciun wrote:
> On Wed, May 2, 2012 at 11:03 PM, Tim Watson<watson.timothy@REDACTED>  wrote:
>> Eric Merit and I have had some lengthy discussions about this on the Erlware mailing list and have some ideas that I think are pretty solid.
>      I'm glad to hear this. (I'll give it a look.)
Cool thanks - please do leave any feedback you feel is relevant.
>> The thing is though, you don't just need tools - you also need people to package their stuff up using the tools.
>      I agree about this. In fact I think currently there are a lot of
> tools with diverging solutions.
>
>      Also I don't think that one "blessed" tool would be the final
> answer. I would have taken a somehow different road, similar maybe to
> how Go is going (although they do have the "one" tool): i.e. strict
> conventions.
Yes I agree that '1 tool to rule them all' isn't going to work. Eric and 
I have discussed building a unix-y pipeline of tools to deal with 
local/remote package and repository management, dependency resolution, 
installing and/or generating a code path (or some other structure) for 
bootstrapping either ERL_LIBS or a call to code:path, etc.

The assumption we have is that various parts can be dealt with be 
different tools providing they respect the APIs, so you can build with 
rebar or sinan or make or whatever. We are also planning on using 
reltool (or some alternative/replica of sorts) to deal with the 
packaging bits, as well as a set of tools for publication, code/package 
signing and the like.

We would also like to support different release types (e.g., embedded 
vs. non), distinguish between applications and library applications and 
so on.
>
>      What do I mean is this:
>      a) it would be nice to have a standardized way to specify "extra"
> options to compile an Erlang module. (We have the module attributes
> that we could use.) (the same for C sources);
>      b) we already have a standard project layout; (i.e. `./src`,
> `./include`, etc.)
>      c) we already have a standard project dependencies (i.e. the `app` file);
>
>      All we need to do is be consistent in this convention, and then
> all the various build and packaging systems could adapt.
Packaging wise, I don't see how any of this really helps so much, 
although I completely agree that sticking to this consistent layout is a 
good thing.

Using the app file for dependencies is fine at runtime - I do this in 
https://github.com/hyperthunk/appstart - but if you're connecting to a 
(possibly remote) artefact repository and fetching stuff, then you need 
to specify the publisher/signer (because 2 OTP applications could be 
written with the same name, and of course with FOSS project forking this 
happens all the time), the application name, and the version. You can't 
whack all of that into your .app file without breaking various things.