updated rebar to heroku/rebar and generated goal module #138
Conversation
|
This is a large change and we should discuss thoroughly with @ericbmerritt before any merging is done :) |
|
Why are there two maintained forks of rebar? |
|
Because rebar/rebar takes forever to get changes merged in. |
|
I had to ping some old pull requests last week to get the erlydtl support in and the maintainers were very responsive. Has anyone from Heroku requested to be a rebar maintainer? It would be good to know why they wouldn't bring in more help. BTW, this build will fail since the travis config is running "make get-rebar && make rebuild" for CI and you're PR is including a rebar bin. Personally, I don't like including bins in the repo. I always install them in PATH. It would be cool if heroku/rebar teamed up with rebar/rebar and helped make a canonical rebar. |
|
Wait, does travis by default use heroku's rebar now? |
|
Also, this isn't passing CI |
|
@jwilberding I didn't want it merged in anyway so passing CI doesn't matter. Wanted to start the discussion. |
|
this is out for discussion more than anything else. So no problem in the On Tue, Mar 11, 2014 at 11:39 AM, Jordan Wilberding <
|
|
@jwilberding no. They were provisioning the rebar from basho. I updated their cookbooks to use https://github.com/rebar/rebar/wiki/rebar bin, but I don't know if they've provisioned that yet. |
|
@nuex yes, they have been a bit better in the recent days, but overall not so. And getting changes like '-r' in may take forever. |
|
I am 100 thousand percent for using heroku's rebar |
|
@jwilberding that's why I had to make the change to do "get-rebar" when in the travis environment. |
|
Yeah, I don't completely agree with how Tristan changed the makefile, but I do want heroku's rebar. |
|
Due to rebar/rebar now finally merging in Tuncer's speedups I am less in favor of going with a fork than I was before, but I'd really like to push some of these sane changes on people like '-r'. |
|
Well a lot of people use relx now, if we start using the other fork, maybe Basho will be more receptive and just accept the changes. |
|
Well the community needs to pick a canonical repo and maintain that one. Whether its heroku/rebar or rebar/rebar. |
|
@jwilberding is basho maintaining rebar/rebar? |
|
No, it is separate from basho. Though I think the main maintainer is Andrew Thompson who does work at basho. |
|
Well basho/rebar has an explicit notice not to use it and use rebar/rebar instead. |
|
What about we open an issue on rebar/rebar and say "Dudes, lets pull in this stuff from heroku/rebar" or "Dudes, lets put up a notice and tell everyone to use heroku/rebar". |
|
Who controls rebar/rebar? |
|
The PRs are open. And they want to continue maintaining at rebar/rebar. |
|
@tsloughter do you have the PR numbers handy? I'd like to check them out. |
|
@jwilberding it is maintained by a few people like Andrew Thompson (Vagabond) |
|
I mean maintaining at rebar/rebar seems logical. It seems to have a more community feel instead of a business/repo feel. |
|
I'm fine with leaving it as is -- partially. Except that it busts on my machine because it uses the rebar that is in your path no matter what version it is. Which is a major pain, one solved by including rebar in the repo. |
|
I'd be ok with that too, I guess. |
|
@tsloughter its breaking because relx isn't compatible with heroku/rebar yet, though, right? |
|
@nuex it breaks because the idea of assuming the rebar in the users path is compatible with the Makefile or even the project it is building (often only a specific version of rebar can successfully build an app) is broken. |
|
There's a discussion about that PR on #erlang right now. |
|
I'm still upset that it sounds like we won't get the recursive fix into rebar/rebar anytime soon (or ever...) which I think is a really important change.... But going to close this for now. |
No description provided.