add rebar.config to makefile

[lazedo]

Hi, how about adding

# Generate rebar.config on build.
app:: rebar.config

to the makefile the way ninenines does for cowboy ?

[hairyhum]

Hi, What would be a purpose for this?

[essen]

It would automatically generate a rebar.config file with valid dependencies and options. This rebar.config file can then be committed to provide compatibility for users of rebar based tools.

@lazedo Have you tried it, does the generated file work?

[michaelklishin]

@lazedo hi, is this still relevant? have you tried what @essen had suggested?

[lazedo]

@michaelklishin yes, its relevant. i tried and it creates the rebar.config. can you add

# Generate rebar.config on build.
app:: rebar.config

to the Makefile in this repo and also to rabbitmq_common ? Thanks

[essen]

Unfortunately it currently does not create a proper rebar.config file.

The reason for that seems to be the custom git_rmq fetch method. I think Erlang.mk needs to be improved first to properly resolve fetch URLs and commits from custom fetch method information, and then this should be doable.

[fenollp]

Not having this rebar.config makes it a little more difficult than usual to use the AMQP Erlang client as a part of another project. @essen Can you work on this?

[michaelklishin]

@fenollp we are definitely interested in making it easier to depend on this client. @essen @dumbbell is it fair to say that erlang.mk needs to be extended before we can provide a rebar.config?

[essen]

Yes there's a few small changes to make. I can do them next week if you want.

[michaelklishin]

@essen I think finishing a few management plugin issues in play is more important but we can look into it after that.

[nxvipin]

Hello everyone! Any updates on this? Official client supporting rebar3 will be great considering that the community is more or less moving forward with this as the official build tool. A (not up to date) fork of this seems quiet popular on hex.pm if the download numbers are any indicator of popularity.

[max-vogler]

Any updates?

[michaelklishin]

No updates.

@essen can you explain what Cowboy does and whether we can do the same thing in this repo (or even for all RabbitMQ repositories)?

[JoshRagem]

I have a sort of workaround for this:

rebar.config

{plugins,
 [
  {rebar_make_plugin, ".*", {git, "https://github.com/JoshRagem/rebar_make_plugin.git", {branch, "master"}}}
 ]
}.

{deps, [
       {amqp_client,   {make, {git, "https://github.com/rabbitmq/rabbitmq-erlang-client.git", {branch, "master"}}}},
       {rabbit_common, {make, {git, "https://github.com/rabbitmq/rabbitmq-common.git", {branch, "master"}}}}
]}.

it's just a small plugin that runs make after cloning a dependency. It only works for master because of something in the makefile system that I did not investigate.

[essen]

I will experiment tomorrow.

[michaelklishin]

@JoshRagem thank you for sharing the workaround!

[essen]

Normally all we need is to add app:: rebar.config to the Makefile, but I'll confirm. :-)

[essen]

We got three solutions for this.

1) We make it fully compatible with rebar and rebar3 by adding a few things to the Makefile (non intrusive) and committing the .app file for both amqp_client and rabbit_common (it will need to be committed only every time a module is added/removed, the default environment variables change, version change, and so on).

2) We use a rebar plugin; problem is that rebar2 plugins aren't compatible with rebar3 and vice versa.

3) We potentially can use hooks but I'm not sure how they differ between rebar2 and rebar3.

I'm more leaning toward the first myself, because this way the rebar.config is auto generated and we don't have to worry about updating things in two places instead of one. Thoughts?

[dumbbell]

I'm currently working on publishing those two projects to Hex.pm. The final goal is to automate that and make it part of the steps when we publish a release.

If we have proper packages on Hex.pm, including amqp_client pulling rabbit_common from Hex.pm, is it enough? Required files could be generated just for this purpose, instead of being committed to Git.

[essen]

It's enough for rebar3 but not rebar (unless rebar received a hex plugin I didn't hear about?). That said, rebar is deprecated and while it still has a fairly large user base, it's presumably only going to get smaller. On the other hand, moving an environment from rebar to rebar3 is no simple task, so there'll probably be rebar users for many more years. Hex-only is fine by me but I shouldn't be the one asked about it. :-)

[essen]

For future reference, this is what is necessary to do for creating a rebar.config in amqp_client:

diff --git a/Makefile b/Makefile
index 9b464ba..af1f6f8 100644
--- a/Makefile
+++ b/Makefile
@@ -31,6 +31,10 @@ ERLANG_MK_COMMIT = rabbitmq-tmp
 include rabbitmq-components.mk
 include erlang.mk

+rebar.config: dep_rabbit_common = git https://github.com/rabbitmq/rabbitmq-common.git $(base_rmq_ref)
+
+app:: rebar.config
+
 # --------------------------------------------------------------------
 # Distribution.
 # --------------------------------------------------------------------

There is no need for a rebar.config in rabbit_common AFAICT. On the other hand the .app would have to be committed with this method.

[dumbbell]

Thank you @essen!

As a first step, we'll publish rabbit_common and amqp_client to Hex.pm which will be enough for rebar3.

To support rebar2, we would have to commit the .app file to Git which doesn't play well with our current Git workflow. Thus we won't add support for it right now, but we may do so in the future.

@lazedo, @fenollp, @max-vogler, @swvist, @JoshRagem, is rebar3/Hex.pm support fine for you?

[JoshRagem]

rebar3/hex.pm is the solution I prefer

[dumbbell]

We published up-to-date versions of rabbit_common and amqp_client to Hex.pm, including the documentation of the Erlang client.

The version is set to 3.6.7-pre.1 because they include commits made after 3.6.6 (including preparation for Hex.pm), but we are not yet at 3.6.7. In the future, we will only publish releases, not work in progress.