[erlang-questions] Building, Packaging and Installing
Torben Hoffmann
torben.lehoff@REDACTED
Mon May 7 15:21:46 CEST 2012
On 04/05/2012 09:32, Tim Watson wrote:
> Is Columbo somehow different from what rebar already does in this space?
One major difference is that Colombo tries to adhere to the version
numbering scheme of OTP and avoids using the source area for generating
releases.
What does that mean?
It means that after building in ./gproc the compiled version will be
installed in ./lib/gproc-0.4.3
This allows a more strict separation of managing dependencies and the
actual building of the app you are working on.
I tried to get rebar to do the same, but it was too painful for me to
get that to work, so I decided to do an experiment of my own to see if I
could create something that could help me out.
Another reason for doing this was to create a set-up so that I could use
sinan as my build tool and since sinan does not deal with dependencies I
had to come up with a solutions for my needs.
I will try to write a blog post and create a Readme for Colombo so that
other can see what I am trying to do more clearly.
In my dreams Colombo functionality is rolled into the major tools once
we agree on the steps in the process, but that is not really up to me to
decide.
Cheers,
Torben
>
>
>
> On 4 May 2012, at 03:06, Tristan Sloughter
> <tristan.sloughter@REDACTED <mailto:tristan.sloughter@REDACTED>> wrote:
>
>> 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 <mailto: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
>> <mailto: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 <mailto: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
>>> <mailto: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.
>>>
>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
--
http://www.linkedin.com/in/torbenhoffmann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120507/73677a09/attachment.htm>
More information about the erlang-questions
mailing list