search

ferd / recon

Collection of functions and scripts to debug Erlang in production.
http://ferd.github.io/recon/
BSD 3-Clause "New" or "Revised" License
1.37k stars 278 forks source link

Add minimal mix.exs #72

Closed dumbbell closed 5 years ago

dumbbell commented 5 years ago

The goal is to be able to use Recon is an Elixir/mix(1)-based project.

If the project can only be built with Rebar, mix(1) complains and asks if it can download rebar3. Not convenient in the middle of an unattended offline build.

dumbbell commented 5 years ago

If you accept this pull request, could you please publish a new version of Recon with this change to Hex.pm? Ideally, 2.4.1 as this would save us from submitting pull requests to other projects to update their version pinning of Recon.

Thank you very much!

ferd commented 5 years ago

The next version of recon is going to be 2.5.0 because of new features introduced that allow people to format maps in traces, as semver dictates -- I just haven't updated the changelog yet as I was letting the changeset simmer. You will have to send PRs to update their versions no matter what.

My gut feeling would be that your offline builds should have their required build environment set in place already and that the download of rebar3 is not a problem with this lib, but with your build environment. Nevertheless, I'm okay with offering a better experience to users as a whole.

Mix is not really part of my workflow, so the one thing I'm worrying about is breaking hex builds for mix users by publishing with the wrong version on the file, but I guess people will yell at me fast enough to provoke a new point build.

Does the empty application entry mean that things like the app description are going to be left empty for Elixir, now that I think about it? It should at least match the info in https://github.com/ferd/recon/blob/master/src/recon.app.src so that it does not represent a regression on users already depending on this app due to a build tool realignment.

dumbbell commented 5 years ago

My gut feeling would be that your offline builds should have their required build environment set in place already and that the download of rebar3 is not a problem with this lib, but with your build environment.

I would agree with that, except that rebar3(1) is available in our environment and is used to build other Erlang-based projects which are not dependencies of Elixir-based projects. I don't understand why mix(1) wants to download a new copy (to put it in ~/.mix/rebar3).

Mix is not really part of my workflow, so the one thing I'm worrying about is breaking hex builds for mix users by publishing with the wrong version on the file

Yes, I have the same problem with other internal Erlang-based projets we have to use in an Elixir-based project. I didn't work on a solution for that yet.

Does the empty application entry mean that things like the app description are going to be left empty for Elixir, now that I think about it?

Good question, you're probably right. Let me fix this.

dumbbell commented 5 years ago

I modified the minimal mix.exs to:

  1. have the same description as src/recon.app.src;
  2. provide no application/0 callback and rely on defaults.

The generated .app file looks similar to the one generated by Rebar 3, with the exception of the Hex.pm-specific keys.