[erlang-questions] Building, Packaging and Installing

[Tristan Sloughter]

Ah yes, I briefly looked at colombo when you mentioned it on the erlware
list. I'll give that a deeper look to see how much of what I need is
covered by it and possibly simply start extending it.

Tristan

On Thu, May 3, 2012 at 4:52 PM, Torben Hoffmann <torben.lehoff@REDACTED>wrote:

> That actually sounds like a good step forward - it almost, but only almost
> makes me sad that I have created my own dependency management tool called
> colombo (alpha vers. is on github/lehoff).
>
> I haven't spent much time on it, but it can fetch apps from git repos as
> well as their dependencies,  one can specify a tag or a branch to check
> out, a simple build can be done and you can get a version tagged version
> installed in the subdir lib of the dir where you you colombo (vers is taken
> from the app file or a default is choosen).
>
> very much alpha quality, but it shows that small dedicated tools aren't
> that hard to create for the Erlang eco system.
>
> I will continue improving colombo since it helps me solve my own problem,
> but it would be nice to have "real" users as well that could help form the
> functionality of the tool. Or tools since I might already have added too
> much functionality to colombo.
>
> Cheers,
> Torben
>
> Sent from my iPad
>
> On 03/05/2012, at 15.30, Tristan Sloughter <tristan.sloughter@REDACTED>
> wrote:
>
> I feel like someone said Travis-CI wasn't the answer... But I am now
> having the thought it is, at least to make something I'd like to see
> without me having to do it.
>
> The question is would the community be interested in this if
> I implement it. Here is what I'm talking about:
>
> 1) A github hook that informs X that an update to a branch or tag is
> pushed.
> 2) This hook does not only ensure tests pass but also that the version
> numbers are correct. If you tag a project as 0.1.0 and the .app file has
> {vsn, 0.1.0} it fails
> 3) Assuming these criteria are met the agner repo for the project is
> either updated or created. Instead of @master it would use a piece of the
> git hash for the branch pointer (using a moving target -- a branch name --
> as the version of an app doesn't make sense), for a tag it would use the
> tag name.
>
> Now, this is only part of the large solution people want, and I agree with
> them we should do.
>
> But, I think it is a start and something that can be done in small enough
> amount of effort to be done soon.
>
> Tristan
>
> On Wed, May 2, 2012 at 7:18 PM, Tim Watson <watson.timothy@REDACTED>wrote:
>
>> On 02/05/2012 21:13, Ciprian Dorin Craciun wrote:
>>
>>> On Wed, May 2, 2012 at 11:03 PMv, Tim Watson<watson.timothy@REDACTED**com<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<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.
>>
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120503/4b297450/attachment.htm>