Wow --- This looks really nice.
I've been focusing on releasing v2.4 and will get more time soon.
Thanks!

Any updates on this pull request?

Thanks for the gentle nudge!
No updates except -- wow why haven't I gotten to this yet?

Hello @LucaCappelletti94! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file networkx/drawing/__init__.py:

Line 4:1: F403 'from .nx_latex import ' used; unable to detect undefined names
Line 4:1: F401 '.nx_latex.' imported but unused

• In the file networkx/drawing/tests/test_adigraph.py:

Line 58:5: F841 local variable 'result' is assigned to but never used

Comment last updated at 2020-06-30 15:51:51 UTC

I removed the conflicts with the master branch and reformatted docstrings and switched names from vertices/vertex to nodes/node. Also format changes to match PEP8, and removed numpy requirements for the tests, as well as making the test class into a test function. I also made some cosmetic code changes.

Questions/concerns/suggestions:

• Should we make a public function like write_latex(G, path) to ease use?
• There are other aspects of the public-facing API that raise questions... Does the basic code need to be inside a figure environment? Should it use subfigures at all (that's for putting together many graphs... which presumably should be done by another program using this one to generate the latex code to draw just the one figure).
• Why does the code cut the x and y layout sizes in half?
• Could we remove the placeholder files and replace them with text strings in nx_latex.py? The files are small. Is there another functionality you aim to include by allowing placeholder files?
• Could the test compare the strings generated rather than writing them to files and comparing those? I think this means, including the expected.tex file as a string and comparing that string to the string generated by str(A).
• Will this code work for DiGraph and MultiGraph?
• Can we make some examples in the doc_string? Or in the examples gallery (directory examples/drawing)?

Thanks!

Looks like the Appveyor tests were having trouble due to matching files with vs without ending linefeeds. It might have also been differences in how files end their lines: with \n or \n\r. But I can't tell for sure (and I don't have access to a windows machine for local testing).

The current test I have constructed writes a file and then reads and compares each line of the written test file and an expected output file. This might be better done using a string rather than writing/reading to files. But it seems to work OK and alleviates the difficulties with trailing end-of-line issues.

Any thoughts on better ways to test this?

I can't get LaTeX to compile using the expected.tex file. It gives an error about too many "," tokens from xparse.

Do I need to install anything, or use a particular flavor of pdflatex/latex/etc to get this to work?

@LucaCappelletti94 can you verify that the expected.tex file that matches the output of A.save is working latex code?
I'm trying to use pdflatex example.tex and it gives a syntax error about extra commas.

Hello @dschult and sorry for the late reply. I am checking it now.

Hello @dschult, I was able to compile the expected.tex on overleaf: https://www.overleaf.com/read/mpyqdcyypfgx

I removed the conflicts with the master branch and reformatted docstrings and switched names from vertices/vertex to nodes/node. Also format changes to match PEP8, and removed numpy requirements for the tests, as well as making the test class into a test function. I also made some cosmetic code changes.

Questions/concerns/suggestions:

• Should we make a public function like write_latex(G, path) to ease use?

I guess it depends on the general expected user usage of the Networkx library. This class was meant to be a stand-alone conversion from a graph to Latex, in a way that it can be easily customized. I guess that a method such as the plot methods that are already present could be used, as no heavy lifting is executed in the constructor of the class.

• There are other aspects of the public-facing API that raise questions... Does the basic code need to be inside a figure environment? Should it use subfigures at all (that's for putting together many graphs... which presumably should be done by another program using this one to generate the latex code to draw just the one figure).

Yes, there is no strict need for figures nor subfigures, but I always found myself in need for one.

• Why does the code cut the x and y layout sizes in half?

I honestly do not remember exactly the meaning of that: I seem to remember that it was needed to properly centre the graph.

• Could we remove the placeholder files and replace them with text strings in nx_latex.py? The files are small. Is there another functionality you aim to include by allowing placeholder files?

I don't think there are contro-indications to put the files into strings, they just felt more modular being separated this way.

• Could the test compare the strings generated rather than writing them to files and comparing those? I think this means, including the expected.tex file as a string and comparing that string to the string generated by str(A).

Yes that definitely makes sense.

• Will this code work for DiGraph and MultiGraph?

It will work for DiGraphs but not for MultiGraphs.

• Can we make some examples in the doc_string? Or in the examples gallery (directory examples/drawing)?

Sure, but I'd need some help to get started with these.

Thanks!

Thank you for your work and sorry for my late reply. This period has been filled to the brink of stuff to do.

Have a nice day!

Thanks very much for this. It looks like my version of adigraph is 1.5.1 and the latest is 1.7.1. That may be the cause of the xparse error complaining about extra commas. Does this make sense?

Is there a version of adigraph that we should require for this to work?

Thanks very much for this. It looks like my version of adigraph is 1.5.1 and the latest is 1.7.1. That may be the cause of the xparse error complaining about extra commas. Does this make sense?

Is there a version of adigraph that we should require for this to work?

When I developed the python wrapper I was using 1.7.x, so I think we should use that one.

I would expect for any updated version of the LaTex distribution to have the latest one (as even overleaf has it, and they update very rarely), considering running the following to update your package:

sudo tlmgr update --self
sudo tlmgr update adigraph

On an unrelated note, I'm finalizing a python + rust backend graph library which has some features that might interest you if you'd like to have a chat after we finish up this pull request.

This PR was closed since Feb apparently due to the original fork being deleted.
I reopened it by creating PR #5639 with these changes.
The adigraph package is still available on CTAN (written by the author of this PR) so it should all still work.

Hello @dschult , I must have done that by mistake. Likely I thought it was a spurious fork. Do you need help putting it back together?

No, it transferred to the new PR just fine. Looks like it'll need updating/rebasing to get the CI to pass. but I think that will be straightforward. Thanks!