-
Notifications
You must be signed in to change notification settings - Fork 284
How to modularize – structure suggestions #215
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
Comments
I'd probably go with a slightly different design
This would allow 3rd party generators if needed. One might even think to get a Maybe add a namespace
|
Regarding plugins and a public API: that is a direction I am open to, but it's too early to implement any of that as part of modularization. Plugins also add many questions of their own, such as “how do we parse command line arguments”. However, I do want to find a structure that allows us to introduce plugins etc. without a second large reorganization. Plugins can be implemented through setuptools entrypoints which does not require namespace packages. “Generator” is a perfect name for the output formats. I think names like I'm not sure what the difference between |
What I'm suggesting is of course a direction and I don't expect to get a stable API or Plugin definition for the next version. All I'm saying is that - and as you said yourself - if it's a direction worth taking, it shall be taken under consideration when defining the new design not to redo things all over again. The question you raised regarding plugin & command-line arguments was one that came to my mind when I wrote this. It adds complexity and does not need to be addressed in a first step.
if What I had in mind was
Then the
Of course, the logic in |
I forgot about I'll try to implement modularization today. |
Implemented in #225. |
When splitting the gcovr script into multiple smaller modules, how should we divide them? In this issue, we can discuss design decisions before settling on a particular choice.
The modularization that was done on the dev branch uses this structure:
gcovr
gcovr.args
parse_arguments()
functiongcovr.data
CoverageData
, and processing of gcov data filesgcovr.driver
main()
function, and amain_()
entrypointgcovr.path
gcovr.version
__version__
declaration andversion_str()
functiongcovr.prints
gcovr.prints.html
print_html_report()
and supporting functionsgcovr.prints.xml
print_xml_report()
functiongcovr.prints.text
print_text_report()
andprint_summary()
functionsI'd prefer a slightly different design:
gcovr.prints
namespacegcovr.app
gcovr.logging
which formats verbose diagnostics and error messagesgcovr.gcov
So I'd probably do:
gcovr
gcovr.app
parse_arguments()
,main()
, entrypointgcovr.coverage
CoverageData
data model that is generated bygcovr.gcov
and consumed by the output formatsgcovr.gcov
gcovr.utils
gcovr.version
__version__
and nothing else, can beexec()
d bysetup.py
gcovr.html
gcovr.xml
gcovr.txt
gcovr.summary
One thing that bothers me with both of these approaches is the rather generic module names like
html
. Wouldhtml_output
be a better name?Are there any alternative suggestions? Any weaknesses with the proposed structures?
Once we've decided on a design, implementing the modularization is going to be fairly easy. Further refactoring can come afterwards.
The text was updated successfully, but these errors were encountered: