[erlang-questions] Non-Erlang dependencies

[Tuncer Ayaz]

On Fri, Jun 29, 2012 at 10:27 AM, Tim Watson wrote:
> On 29 Jun 2012, at 06:43, Anton Lavrik wrote:
>
> > On Thu, Jun 28, 2012 at 6:07 AM, Tim Watson wrote:
> > >
> > > On 28 Jun 2012, at 10:56, Benoit Chesneau wrote:
> > >
> > > > On Thu, Jun 28, 2012 at 11:49 AM, Loïc Hoguin 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.

Commented in the pull request after realizing a couple more issues.
Let's continue the patch discussion over there.

> 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!

Tim, let me say I'm glad that you push the limits of the existing
plugin system :).

Some patches are not universal enough or an easy fit to be applied to
rebar master as is. Therefore it's usually a good idea to let such
patches exist as plugins first. If it proves to be popular and the
implementation has been tested/refined, it will be much easier to
consider a merge. Also, compiler plugins for alternative languages are
best distributed with their compiler. Finally, having a tried and
tested external plugin gives us great insight to consider core changes
making proper solutions possible.

Interested rebar users might want to consider helping with ta-state
by giving it a spin and reporting all issues.

For details see
http://lists.basho.com/pipermail/rebar_lists.basho.com/2012-June/001623.html
There's a known issue with list-deps when run on
https://github.com/hyperthunk/eunit_cover_example. Should be fixed
this weekend.