Migrate to rebar3 or mix

[wohali]

We're long past due upgrading to rebar 3 (latest).

This requires using @davisp's erlang-native-compiler to continue to build our NIFs.

[tsloughter]

You might find it easier to use https://github.com/blt/port_compiler/ instead of having to call out to the external enc escript just to build NIFs.

[davisp]

The issues I had trying to use port_compiler is precisely what motivated me to write enc in the first place. I haven't paid any attention at all to changes to port_compiler in the meantime but that's precisely because I've not had any issues reported with enc in the nearly two years since I last touched it.

I'm not against changing back to port_compiler if someone wants to take a stab at it.

[nickva]

I started on this a while back:

cloudant@b0f3fee

Besides the port compiler issue the other one was using raw dependencies (Fauxton and docs). rebar3 doesn't do those by default (or didn't do when I checked): erlang/rebar3#110 There might be a plugin to handle those. The other option could be to make a "fake" Erlang OTP directory structure in those dependencies.

[tsloughter]

Yea, there is a raw resource plugin that can be used.

[iilyak]

I think we should consider trying out mix (Elixir build tool) instead of rebar3. Although we would have same compatibility issues as with rebar3 (NIFs and raw deps). Nevertheless I find mix implementation faster and easier to hack on. I am happy to go with any direction the community would decide to pursue.

[garrensmith]

+1 to using mix

…

________________________________ From: iilyak <notifications@github.com> Sent: Monday, March 18, 2019 7:01 PM To: apache/couchdb Cc: Subscribed Subject: Re: [apache/couchdb] Migrate to rebar3 (#1428) I think we should consider trying out mix (Elixir build tool) instead of rebar3. Although we would have same compatibility issues as with rebar3 (NIFs and raw deps). Nevertheless I find mix implementation faster and easier to hack on. I am happy to go with any direction the community would decide to pursue. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1428 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAK9AteE0ppVBV9_9dRYjSHLwZ8qOzyEks5vX8ZcgaJpZM4VH-DS>.

[eiri]

I'd +1 for trying mix too. I don't have an opinion on it itself, but I personally don't find rebar3 a significant improvement over "classical" rebar.

[tsloughter]

:(

I don't work on couchdb so my opinion doesn't matter here, but I am always interested in ways to improve rebar3, so please pass along (probably not on this issue unless it somehow directly relates to the question of couchdb migration) any suggestions or complaints (particularly how it doesn't do better than rebar2 which was one of the main goals and why it was essentially a rewrite).

rebar3 is fairly different from mix, so personal preference for one or the other over particular decisions we made differently is an understandable separation that can't necessarily be bridged, but always interested in hearing about them.

[wohali]

@tsloughter Thanks so much for stopping by!

The big issues for us when rebar3 dropped were problems with NIFs (why @davisp had to build enc.), coupled with the problems Nick mentioned on raw dependencies, and some Windows compile issue (probably NIF related) I ran into that I can't remember. Because that was early and we were waiting, you have probably fixed some or all of these by now, but this hasn't been a high priority ticket. It's becoming more important as we look at architectural changes to CouchDB and newer versions of Erlang.

While mix is interesting, it matters more in my opinion if we're going to start accepting Elixir as a core language, not just for our test suite. Either way, I don't have the cycles to drive the work on either, so I hope someone picks up either and runs with it.