I went in and made some changes to make it work with the CI, @LucaCappelletti94 I also removed the type annotations as currently we don't actively put in type annotations for code in networkx (it was also failing the mypy check).

@dschult @LucaCappelletti94 it would be great to get this in before 3.0 (but it's supposed to be released in 2 weeks) and I would be great to get the issues brought up (and replied) in #3591 (comment) resolved ! :)

The one major thing that sticks out to me is the API of write/read of LaTeX graphs, this should follow (IMO) the generic drawing API like read_dot and write_dot.

Users should be able to do something like:

>>> G = nx.erdos_renyi_graph(10, 0.1)
>>> nx.write_latex(G, 'erdos.tex') # which creates a Adigraph object and writes to file

I would suggest that we follow the API choices in nx_agraph.py as an example:

from_adiraph and to_adigraph that handles conversion between a NetworkX (Di)Graph object and a Adigraph object. This will let users interact with the Adigraph object itself and provide helper functions like write_latex and read_latex so users can quickly write a NetworkX (Di)Graph object to disk.

Many of the readwrite formats allow: read_*, parse_*, write_*, generate_* with "parse" and "generate" constructing the string while "read" and "write" putting the string into a file.

Another questions with latex output is whether the resulting tex file should include only the latex code for the drawing or whether it should also include the header/footer for a standalone document. Perhaps we want a keyword argument for that?

Finally, @LucaCappelletti94 how likely is adigraph to continue to be supported/work from CTAN?

Well the package uses old latex APIs, basically no dependencies, so I don't think it will cease to work. As per additional features, I wouldn't know, for all intents and purposes for me it is a finished job. Still, I am currently working on a rust graph library for graph machine learning things, so it is possible I'll find the need to add some new stuff there from time to time.

Another API choice of Adigraph is that it stores many graphs and writes them each in a separate subfigure within a figure environment. I am assuming this is better than storing each graph as its own Adigraph because you can set drawing attributes for all the graphs at once. But our other drawing routines only draw one graph and take as inputs the drawing options. You can store these options in a dict and pass that dict into each drawing object.

Current use:

A = nx.Adigraph()
A.add_graph(G1, node_color="green")
A.add_graph(G2, node_color="red")
A.save("figure_with_subfigures_1and2.tex")
# The tex file is now ready to produce a document with a single figure 

Alternate API:

A1 = nx.Adigraph(G1, node_color="green")
A2 = nx.Adigraph(G2, node_color="red")
nx.write_latex(A1, "subfigure1.tex")
nx.write_latex(A2, "subfigure2.tex")
# There are now 2 tex files ready to be used with \input (or copy/paste) in a bigger document.

What's better? Should Adigraph be related to one graph or to one figure with potentially many graphs?

@LucaCappelletti94 I'm confused about the difference between "weight" and "label" for edges in adigraph.
The pdf documentation file seems to suggest that the presence of a label means that the weight is not displayed. So, is there any impact of the weight when a label is there?

node,nbr,clr,wdth:wt:lbl               -> does not show the wt, only the lbl
node,nbr,clr,wdth::wt                   -> shows wt as a label
node,nbr,clr,wdth:wt                   -> Is this any different from the previous line?

I must admit I don't recall anymore, I wrote the thing initially to drow augmenting directed graphs, so it may have to do something about that. I'll re-read how I process them in the source code and get back to you.

Ah yes, basically the thing was that the whole library was initially for drawing augmenting paths on graphs, and as such, it needed the edge weights for the path when the augmenting paths feature was used, even when the weight was not displayed.

@LucaCappelletti94 I've got some more questions for you about Adigraph. :}

• What are the possible values of style? The pdf documentation has "", "-" and "dashed" (each put inside square brackets for LaTeX's optional argument syntax). Are there other styles? Are these part of tikz styles?
• What are the possible values of label position? Examples given are "near start" and "near end". Are there others? Is there functionality for how near?

Thanks very much!

Hello @dschult, I'll go take a look at the code and let you know. As of now I don't recall.

Ok so, both style and label position can be anything that tikz accepts.

Awesome-- Thanks.
Is there a good link to docs for what tikz accepts? :} That'd be too easy, I know... :}

Probably the best link for the docs for tikz styles and label positions is:
https://tikz.dev/ and in particular for node and edge attributes: https://tikz.dev/tikz-shapes

The most general answer is that it can be anything previously defined as a tikz style.
So, we can just say that in our docs and provide a few examples.
I saw "dotted" and "dashed" in the examples in the tikz docs.

Yes, I would also go for linking the tikz documentation, and saying it can be just about anything supported by tikz plus adding some examples.

Potentially interesting https://github.com/tardis-sn/tardis/blob/master/tardis/plasma/base.py#L354

That potentially interesting link shows code which uses a package dot2tex.
So, it looks like a possible path to get to latex files is to use pygraphviz to turn a NetworkX graph into a dot file and then convert the dot file to tex. I'd still prefer a direct nx2tikz approach, but it is good to see an alternative. :)

Let's switch focus for this issue/PR to #6238