Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

standardized, reusable output formats (e.g json and png) #92

Open
danwos opened this issue Oct 23, 2019 · 9 comments
Open

standardized, reusable output formats (e.g json and png) #92

danwos opened this issue Oct 23, 2019 · 9 comments
Assignees

Comments

@danwos
Copy link
Contributor

danwos commented Oct 23, 2019

Providing more standardized output formats for diff, report and graph to support the development of tools on top of wily.

To embedded the wily results automatically (CI) in other tools/documents, a machine readable format would be great.

use cases

The graph output could be easily integrated into word-docs or wiki-pages, if png as output format is supported.

The report and diff output as json string/file would allow a CI to evaluate the results during build and maybe reject a commit because of too high complexity.

my motivation

I'm personally thinking of creating an extension for sphinx: sphinx-wily.
To get the wily results easily into a documentation during build time.
But I want to avoid parsing any kind of cli-output, if it is not using any standard (too risky that such an output gets changed over time).

I may find some time to dive into wily and provide a PR which implements at least a json output.
But no guarantee for this.

So any thoughts or concerns regarding additional output formats?

BTW: Thanks for this great tool. Performing an analysis over the git history is really an awesome feature.

@tonybaloney
Copy link
Owner

The tabular module used by the library supports JSON, (from memory) you can override the table style to json using a command-line option to accomplish what you're suggesting with --console-format json

It's not an advertised feature though.

@tonybaloney
Copy link
Owner

For graph, if the graphing library supports that, I'd be keen.

@tonybaloney
Copy link
Owner

Maybe a generic --json flag to all commands would make this more obvious?

@tjysdsg
Copy link

tjysdsg commented Feb 3, 2020

I think it's better to also make wily rank output standardized. In addition, it's a great idea to support csv output to file

@devdanzin
Copy link
Collaborator

The graphing library does support it: https://plotly.com/python/static-image-export/

It requires a dependency, Kaleido, that weighs at about 65MB. Other than that it seems straightforward to add PNG exports. I intend to add code for that for my personal use and would be glad to contribute it if the new dependency is acceptable.

@devdanzin
Copy link
Collaborator

In addition, it's a great idea to support csv output to file

Tabulate allows outputting as TSV, which should be enough, with --console-format tsv. I'll investigate whether it works soon.

I can't seem to find JSON support in Tabulate, but converting from TSV to JSON should be easy if we want to offer that format.

@devdanzin
Copy link
Collaborator

Tabulate allows outputting as TSV, which should be enough, with --console-format tsv. I'll investigate whether it works soon.

It doesn't work, it's just a cosmetic output option that resembles TSV. However, building a JSON stream from the data we pass to Tabulate is straightforward. Please take a look at linked #194 to check whether it addresses your need.

@devdanzin devdanzin self-assigned this Aug 16, 2023
@osunderdog
Copy link

It would be helpful if there was a 'model' definition for each report so that the ouput formats available for a report could be extended. For example, some output formats that might be useful as extensions:

to_dataframe
to_database

These don't have to be done in wily where you want to keep it lean, but if there was a report model class, then a ambitious customer could write the extension (inherit from report model class) themselves and import pandas for that work without requiring wily to import pandas.

It would also be useful to separate cases where two values are shown in one column. This is great for presentation, but a data scientist would have to cleanse the column into two separate columns for analytics.

I think this abstraction between model and view is missing here and it will hurt future efforts to enhance.

@devdanzin
Copy link
Collaborator

Thank you very much, your feedback makes a lot of sense! I'll first try to solve the multiple values per column, then work on extensibility. The model/view insight is very useful!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants