add rebar.config to makefile about rabbitmq-erlang-client HOT 23 CLOSED

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.

from rabbitmq-erlang-client.

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.

from rabbitmq-erlang-client.

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.

from rabbitmq-erlang-client.

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

from rabbitmq-erlang-client.

Hi,
What would be a purpose for this?

from rabbitmq-erlang-client.

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?

from rabbitmq-erlang-client.

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

from rabbitmq-erlang-client.

@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

from rabbitmq-erlang-client.

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.

from rabbitmq-erlang-client.

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?

from rabbitmq-erlang-client.

@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?

from rabbitmq-erlang-client.

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

from rabbitmq-erlang-client.

Any updates?

from rabbitmq-erlang-client.

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)?

from rabbitmq-erlang-client.

I will experiment tomorrow.

from rabbitmq-erlang-client.

@JoshRagem thank you for sharing the workaround!

from rabbitmq-erlang-client.

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

from rabbitmq-erlang-client.

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?

from rabbitmq-erlang-client.

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.

from rabbitmq-erlang-client.

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. :-)

from rabbitmq-erlang-client.

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.

from rabbitmq-erlang-client.

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?

from rabbitmq-erlang-client.

rebar3/hex.pm is the solution I prefer

from rabbitmq-erlang-client.