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 On Sun, Jun 4, 2017 at 1:11 PM, Michał Muskała <[email protected]> wrote: > 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ł. > > -- > 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 [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/eff36d47-67be-448d-9454-cb140a41723d%40Spark > <https://groups.google.com/d/msgid/elixir-lang-core/eff36d47-67be-448d-9454-cb140a41723d%40Spark?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KVRGxCKjaDZ707PGBHo%2Bn%3D%2BxR82xps6sfkkHNWFqwp3Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
