non-otp dependencies

Sean Cribbs sean at basho.com
Wed Dec 1 08:10:19 EST 2010


I've already done the work to make bert.erl rebar-compatible, you can use my fork. Now if we could just get Tom to merge the pull request...

http://github.com/seancribbs/bert.erl

Sean Cribbs <sean at basho.com>
Developer Advocate
Basho Technologies, Inc.
http://basho.com/

On Nov 30, 2010, at 11:07 PM, Woody Peterson wrote:

>> I know this sidesteps your question, but it would be _really easy_ to package bert.erl as an OTP "library" application.  Just add a src/bert.app.src file with the basics.  I like the fact that rebar is opinionated in this respect.
> 
> I agree, and am happy to hear someone else like that solution. I was reading the otp application docs and the whole context for .app files seems to be for starting/stopping processes, so in one light a .app file for a collection of functions could be seen as overkill. I can also see it as in-code documentation of the simplicity of a library, and I'm a fan of conventions. I think that's the approach I'll take, thanks for the feedback.
> 
> On Nov 30, 2010, at 7:55 PM, Adam Kocoloski wrote:
> 
>> I know this sidesteps your question, but it would be _really easy_ to package bert.erl as an OTP "library" application.  Just add a src/bert.app.src file with the basics.  I like the fact that rebar is opinionated in this respect.  Regards,
>> 
>> Adam
>> 
>> On Nov 30, 2010, at 10:49 PM, Woody Peterson wrote:
>> 
>>> Hi all,
>>> 
>>> Rebar compiles all deps as it does the main app, and since it's designed for OTP packaging, it assumes all deps are OTP also, which makes sense. My question is about how to package a non-otp dep.
>>> 
>>> I have a project with a dependency on bert.erl (https://github.com/mojombo/bert.erl), a *really* simple project that only defines serialization functions and is just 1 /src file and 1 /test file. This presents 2 problems, one being that no .app file means rebar can't calculate the version when it does get-deps, the other that it won't work with the compile task; it will silently do nothing, as was discussed previously on the list.
>>> 
>>> I've seen other projects just grab function-only files they need from another project and put them in /src, but that seems less than ideal. I suppose this could be more of an otp design question, but how can I explicitly package this non-otp dependency? If the answer is to put it in deps as I have in the past, and rebar decided to support this case, it would mean a) allowing versionless dependencies (which I took a seemingly successful stab at in 3 lines), and b) compiling every .erl in src/ to /ebin even w/o .app, which I haven't looked into at all, but has had a lot of discussion recently on the mailing list.
>>> 
>>> For the latter, David has mentioned re-thinking some of the recursive parts of rebar, what would you think of checking for rebar/Makefile/Rakefile and executing the appropriate build tool, leaving compilation steps in the hands of the dependency? It would definitely have less happy-path functionality than it does currently, maybe that could be a fallback behavior / config option?
>>> 
>>> Thanks in advance,
>>> 
>>> -Woody
>>> 
>>> _______________________________________________
>>> rebar mailing list
>>> rebar at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com
>> 
> 
> 
> _______________________________________________
> rebar mailing list
> rebar at lists.basho.com
> http://lists.basho.com/mailman/listinfo/rebar_lists.basho.com




More information about the rebar mailing list