Review Request 115495: Make kgenframeworksapidox generate dependency diagrams

[Alex Merry]

> On Feb. 6, 2014, 12:56 p.m., Alex Merry wrote:
> > Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb).  You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams).
> > 
> > Second thing: why call dot directly instead of using yapgvb to render to PNG?  Although it looks like tred might not be an option in that case...
> > 
> > Third thing: have you tested with python3?
> 
> Aurélien Gâteau wrote:
>     > Instant issue: the README.md claims that yapgvb is only needed to generate the diagrams, but not having it installed causes kgenframeworksapidocs to fail with an ImportError (it imports depdiagram, which imports yapgvb).  You need to catch and handle that ImportError in a sensible way (perhaps produce an error if the user asked for dep diagrams).
>     
>     Good point. Will fix.
>     
>     > Second thing: why call dot directly instead of using yapgvb to render to PNG?  Although it looks like tred might not be an option in that case...
>     
>     I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this.
>     
>     > Third thing: have you tested with python3?
>     
>     No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter.
>     
>
> 
> Alex Merry wrote:
>     > I don't trust yapgvb much as it has proven to be not very stable, so I'd rather use the minimum from it. Furthermore, as you said, we would not be able to use tred. An alternative approach would be to store the end diagram as a .dot file and let Doxygen do the rendering, though I am not sure we would gain much from this.
>     
>     Fair enough, although did you look at pygraphviz as an alternative?  That appears to mostly interface with the tools.
>     
>     > No. I don't think we should care too much about Python 3. I'd rather have it well debugged and working with one interpreter.
>     
>     Currently, I believe it's running under Python 3 on the EBN (although Python 2 is available there).  So... that's something to consider.
> 
> Aurélien Gâteau wrote:
>     > Fair enough, although did you look at pygraphviz as an alternative?  That appears to mostly interface with the tools.
>     
>     I did: the problem with pygraphviz is that it does not extract enough information: a node is just a string, which is not enough because we need to know the node shape to determine the target kind (see TARGET_SHAPES in frameworkdb.py).
>     
>     > Currently, I believe it's running under Python 3 on the EBN (although Python 2 is available there).  So... that's something to consider.
>     
>     Oh, I did not know that. That would be a problem: right now yapgvb does not build with Python 3, and since the project is quite inactive, I doubt it is going to change anytime soon.
>     
>
> 
> Aurélien Gâteau wrote:
>     Allen just told me the Python version used is 2.7.5.

Oh, OK; I know the EBN has several versions available from my discussions with Ben.  I got the impression that 3.2 was the one being used, but I guess Allen's decided to run it on a different one.


- Alex


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115495/#review49120
-----------------------------------------------------------


On Feb. 6, 2014, 2:05 p.m., Aurélien Gâteau wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115495/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2014, 2:05 p.m.)
> 
> 
> Review request for KDE Frameworks and Aurélien Gâteau.
> 
> 
> Repository: kapidox
> 
> 
> Description
> -------
> 
> This big patch moves code from depdiagram-prepare and depdiagram-generate to Python modules and make kgenframeworksapidox use those modules to generate the dependency frameworks.
> 
> This only happens when it is called with the --dependency-diagrams option.
> 
> Since the patch is going to be painful to review here, I also uploaded the patchset here: http://agateau.com/tmp/kapidox-depdiagram-integration
> 
> 
> Diffs
> -----
> 
>   README.md 6a4a4a8 
>   docs/depdiagrams.md PRE-CREATION 
>   src/depdiagram-generate adabe27 
>   src/depdiagram-prepare 3d133d9 
>   src/kapidox/__init__.py 0024723 
>   src/kapidox/data/dependencies.md 5e30d09 
>   src/kapidox/data/dependencies.md.mustache PRE-CREATION 
>   src/kapidox/depdiagram/__init__.py e69de29 
>   src/kapidox/depdiagram/frameworkdb.py 9b63c8b 
>   src/kapidox/depdiagram/generate.py PRE-CREATION 
>   src/kapidox/depdiagram/prepare.py PRE-CREATION 
>   src/kgenframeworksapidox ac34f2c 
> 
> Diff: https://git.reviewboard.kde.org/r/115495/diff/
> 
> 
> Testing
> -------
> 
> Generated the whole thing, works as expected.
> 
> 
> Thanks,
> 
> Aurélien Gâteau
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140207/b260e0c6/attachment-0001.html>