[erlang-questions] Non-Erlang dependencies

[Tim Watson]

On 29 Jun 2012, at 06:43, Anton Lavrik wrote:

> On Thu, Jun 28, 2012 at 6:07 AM, Tim Watson <watson.timothy@REDACTED> wrote:
>> 
>> On 28 Jun 2012, at 10:56, Benoit Chesneau wrote:
>> 
>>> On Thu, Jun 28, 2012 at 11:49 AM, Loïc Hoguin <essen@REDACTED> wrote:
>>>> No actually this is interesting. I *think* I can have a small script in a
>>>> get-deps post_hook to fetch the extra dependencies when you get the Erlang
>>>> ones. This way you download everything at the same time.
>>>> 
>>>> I'll try it out.
>>>> 
>> 
>> That will work fine, just don't *declare* them as dependencies, otherwise rebar will puke when it doesn't find an application resource file. There is a patch in the rebar pull request queue which adds support for non-otp (raw, as the author puts it) dependencies, which just get downloaded but not checked for OTP compliance. If you like this feature, please go vote for it as @dizzyd and @tuncer are deliberating at the moment. I'm going to up-vote it (after playing devil's advocate for a while) as I'd like to use deps for both things without messing around with hooks.
> 
> It would be great if you up-voted it. Otherwise, your comments to the
> pull request could be interpreted as if you were uncertain about it.
> 
> In fact, @tuncer told me that he didn't want to make that decision
> leaving it to @dizzyd. One of the reasons was because @dizzyd was
> going to do some significant internals rework and @tuncer wasn't sure
> how this change would fit in.
> 
> Unfortunately, @dyzzyd is not being responsive. Does anybody know who
> else might be able to make the decision of accepting and merging this
> change?

You should be aware that some pull requests can take a long time to get through. I have some that are *really* old but only because I haven't closed them having agreed with the rebar developers that they won't merge them but pending some alternative resolution. I'm going to tidy those up this weekend. I *will* go and up-vote this, but anything to do with deps is tricky to decide on and don't be surprised if it takes a while.

Anyway I wouldn't worry too much about this at all! Firstly you can of course use your own rebar fork in your own projects, but more significantly (IMHO) there is a soon to be merged branch ta-state which, when it does get merged, will allow you to completely customise the way anything (including deps) works from a locally (or globally) configured plugin and your [raw] feature can easily be supported for every rebar project that wants it without actually changing rebar at all. I package and distribute a number of global/general-purpose plugins which are used across 80% of my rebar based projects and this process is already very slick and easy and when ta-state gets merged, it will be simple to make features that even change core functionality such as adding support for non-otp deps and bundle this as a plugin without changing even the way you configure your projects or invoke rebar or anything. It's going to be awesome (can you tell I'm excited about it!?) because instead of sitting in a pull request queue debating whether or not what you want to do makes sense, you can just do it and distribute it via github and use it wherever you want to. And if it *does* make sense probably a bunch of other people will start using it and you'll be managing your own pull request queue instead of sitting in someone else's!

Cheers,
Tim