[Proposal] mix report

[Michał Muskała]

Hello everybody,

When a bug is reported (be it to elixir itself or any other project), maintainers usually need some additional information about the system to debug the issue. Right now this is achieved across the core elixir projects using issue templates on GitHub asking some questions. 

Extracting all this information and filling it by hand is tedious and error prone. Fortunately, we're programmers, so we can automate it!

I propose introduction of a new mix task called "report" that will collect this kind of information and print it to the screen, ready to be pasted into the issue template.

One obvious issue is that different projects might need different information - e.g. ecto is asking for the database version, phoenix is asking for node & brunch versions, etc. Because of this, the task needs to be extensible. Since this concerns mix projects, the obvious point of extension is mix.exs - I propose additional `report` option in the project config that should return a zero-arity fun, which once called will return a map with simple key-value pairs of information to print.

This should allow phoenix to discover the version of node, and, for example, all the node packages. For ecto it will be possible to discover the database version for the default adapters, and for additional adapters, the version of the database they support. I could also imagine, for example, distillery collecting some additional information.

The structure of the output should be as follows:

* System information

  - OS information

  - erlang version

  - elixir version

  - any system env affecting how elixir behaves

  - any installed archives

* Dependencies

  - list all dependencies and their versions

* For each mix project that provides the report callback print the data

This might be a lot of data, but GitHub allows wrapping it in a nice <details> tag, which makes it foldable. This means it shouldn't be a huge issue in practice and should help significantly with debugging issues.

An alternative would be to post all this information to a GitHub gist (the API is open) and provide user with a link that could be pasted in the issue template. I'm not sure how problematic that's going to be with httpc.

Michał.

[José Valim]

I think this is a great idea.

Question: if someone is using Ecto and Phoenix, and they need to open up a bug in Ecto, how can they do so without all of the Phoenix metadata?

That said, wouldn't it be better for each of those projects to introduce report.ecto / report.phoenix individually? Then they have full control on the report. If by any chance we see some duplication, then we can introduce helper functions. That would be more flexible than wrapping the whole functionality.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/eff36d47-67be-448d-9454-cb140a41723d%40Spark.
For more options, visit https://groups.google.com/d/optout.

[Michał Muskała]

On 4 Jun 2017, 13:39 +0200, José Valim <jose....@plataformatec.com.br>, wrote:

I think this is a great idea.

Question: if someone is using Ecto and Phoenix, and they need to open up a bug in Ecto, how can they do so without all of the Phoenix metadata?

That said, wouldn't it be better for each of those projects to introduce report.ecto / report.phoenix individually? Then they have full control on the report. If by any chance we see some duplication, then we can introduce helper functions. That would be more flexible than wrapping the whole functionality.

 

I was thinking about this and I'm not sure this is better. There might be some additional information, but if everything is properly sectioned, I don't think it's going to be a huge issue. It will also "just work" for projects that don't need to add additional information. Another thing to consider is that often, an issue created in phoenix is actually something wrong with ecto, so having all this information already there would be helpful.

Having one task creates an excellent workflow - do you have any issues with something elixir-related? Run `mix report` and open an issue. That's it. With separate tasks, you need to figure out the appropriate task to run - first find out if it's even there.

If we really want to push it, GitHub new issue link allows passing title & body query options to fill the template. I could imagine running `mix report phoenix` which would open an issue on the phoenix repo with filled template (provided project has the GitHub link). That might be going a bit too far, though.

[José Valim]

> If we really want to push it, GitHub new issue link allows passing title & body query options to fill the template. 

Actually, automatically opening up a page with data filled is one of the reasons I prefer individual tasks. We can also have a `mix report` task that asks:

Do you want to open up an issue for?

1. elixir

2. ecto

3. phoenix

And the list is based on the available report.* tasks.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--

You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4564c0ed-a1eb-4ccd-bc40-9fb018a9b4ab%40Spark.

[Michał Muskała]

That could work. In a similar way to how we have the compilation tasks.

Michał.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J%3DRF7BHCYVdejQaVSragrNkrq%3DQnv9-49JvHV_UOqbig%40mail.gmail.com.

[Wojtek Mach]

Excellent idea, Michał! I started experimenting with it at https://github.com/wojtekmach/mix_report. I have basic issue reporting for Elixir and (temporarily vendored) for Ecto.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/4564c0ed-a1eb-4ccd-bc40-9fb018a9b4ab%40Spark.

For more options, visit https://groups.google.com/d/optout.