graphviz: Update to 2.49.1

[jarrodmillman (Jarrod Millman)]

I am a code developer of PyGraphviz (​https://github.com/pygraphviz/pygraphviz) and NetworkX (​https://github.com/networkx/networkx). Some of our users use macports. Unfortunately, the version of Graphviz that you distribute (2.40.1) doesn't work well with Pygraphviz b/c of several known bugs. I believe Graphviz 2.40.1 came out in 2016 and they've made a lot of improvements since then.

It would be great if you could update to the current stable release (2.49.1): ​https://gitlab.com/graphviz/graphviz/-/blob/2.49.1/CHANGELOG.md

[ryandesign (Ryan Carsten Schmidt)]

Yes, and graphviz-devel should be updated too. Since it has been so long since I updated the ports, there is much to be modernized in the ports.

[jjstickel (Jonathan Stickel)]

I was able to update graphviz to 2.46 and py-pygraphviz to 1.7 in a ​branch on my fork.

The graphviz Portfile is quite involved. I made only the minimum edits needed to get graphviz installed with the default variants. I did not test the other subports nor variants. I didn't make a PR yet because I presume Ryan would like to have further revisions

I don't know the history, but is graphviz-devel necessary now? It looks like graphviz has been making a ​release every few months during the last year.

Updating py-pygraphviz was trivial and should be good to go once graphviz is updated in the Macports repository.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jjstickel:

I was able to update graphviz to 2.46 and py-pygraphviz to 1.7 in a ​branch on my fork.

The graphviz Portfile is quite involved. I made only the minimum edits needed to get graphviz installed with the default variants. I did not test the other subports nor variants. I didn't make a PR yet because I presume Ryan would like to have further revisions

Thanks for beginning this process. If those minimal changes allowed the main port to build, that's good. What macOS version did you try it on?

When I had tried to update the port, I was also trying to solve #58126, which is a general MacPorts problem reported in #57137. Is this problem no longer encountered with your updated graphviz port, or did you only not see it because you tried it on an older macOS version? We can certainly update the port first and then solve this later if it's still a problem.

Updating this port will also resolve #59026.

I don't know the history, but is graphviz-devel necessary now? It looks like graphviz has been making a ​release every few months during the last year.

graphviz is mature software. We could certainly phase out the graphviz-devel port. It existed in order to track the development releases that the graphviz developers used to produce frequently while graphviz was hosted at AT&T. Back then stable releases of graphviz might only occur a couple times a year and there were times when one would want to try a fix that had been committed but which had not yet made it into a stable release.

Updating py-pygraphviz was trivial and should be good to go once graphviz is updated in the Macports repository.

[jjstickel (Jonathan Stickel)]

I tested on Catalina.

I can work on and test a couple more subports and variants, but I don't have time to try all of them. Perhaps you could let me know what to prioritize.

[ryandesign (Ryan Carsten Schmidt)]

Well there are only two subports—graphviz-gui and gvedit—in addition to the main graphviz port that you've already tested. Would be good to verify that the two subports install. (And it is the graphviz-gui subport that would be affected by the aforementioned #57137 problem on macOS Mojave and later.) That's the extent of what I usually do when updating a port.

[jjstickel (Jonathan Stickel)]

I am trying gvedit. I get this error:

Error: Failed to extract gvedit: cannot find GVEdit short version string

I see the sed line in the Portfile, but I am not sure what it is trying to do.

[jarrodmillman (Jarrod Millman)]

The current stable release is 2.46.1 now: ​https://gitlab.com/graphviz/graphviz/-/blob/master/CHANGELOG.md#2461-2021-02-13

It does mention a gvedit fix, but I don't know if it is related to the issue you are seeing: ​https://gitlab.com/graphviz/graphviz/-/issues/1862

[ryandesign (Ryan Carsten Schmidt)]

The Portfile tries to extract the GVEdit version number from a known location in the source code. That location has apparently changed by this point in GVEdit's development, so you would need to investigate where the version number is now stored in the source and adjust the command accordingly.

[Smattr (Matthew Fernandez)]

Hello, I am one of Graphviz' de facto maintainers. Thanks Jarrod for pointing me here.

I'm not a Macports pro, but I think the Portfile referred to above is ​https://github.com/macports/macports-ports/blob/master/graphics/graphviz-devel/Portfile or ​https://github.com/macports/macports-ports/blob/master/graphics/graphviz/Portfile. Some thoughts:

• Graphviz still does the development releases, but I honestly don't know who is using them. The reality is that they are no more or less stable or tested than the "stable" releases, so I would simply like to move to a more frequent release cadence.
• The post-patch step in those Portfiles that is doing stuff related to libc++ is I believe trying to work around ​https://gitlab.com/graphviz/graphviz/-/issues/163. We resolved this in Graphviz commit 3dd185241646d10149c86899f3a99beb51fce5d9 (a mere 5 years after @ryandesign diligently reported it...) which made it into release 2.46.0, so I believe this should no longer be necessary.
• We had to unfortunately yet again migrate where Graphviz downloads are hosted, so the livecheck probably doesn't work. See ​https://gitlab.com/graphviz/graphviz/-/issues/1371 for more details.
• The Portfiles have various references to Qt4, but we dropped Qt4 support in Graphviz commit 32abc6416f2e87f00b009e7f526102c5d937a933 which made it into release 2.46.1. I'm unsure how much pain migrating to Qt5 causes you.
• Maybe the GVEdit regex is trying to match this line in the source? ​https://gitlab.com/graphviz/graphviz/-/blob/master/cmd/gvedit/mainwindow.cpp#L273 I was not aware of this until just now and I don't know why we give GVEdit a separate version number instead of just the Graphviz version number itself.

Graphviz maintenance is challenging because (a) most of our users are on Windows or macOS, (b) most of the maintainers have no access to Windows or macOS, and (c) many users are using Graphviz via something else (e.g. PyGraphviz), which makes them hugely productive but often unable to explain how to reproduce their issues using pure Graphviz. I myself have no GUI environment on my Graphviz development machine, so I mostly try not to touch GVEdit as I have no way of running or testing it.

If there's anything we can do on our side to ease future packaging, please let us know. For my own part, I've been trying to strip as much "magic" out of the Graphviz build system, reduce dependencies, and remove non-portable code.

[jjstickel (Jonathan Stickel)]

Thank you Matthew for the detailed information.

I spent a couple hours on that sed-regex line to get the version number and couldn't figure it out. I'll probably just hard-code the GVEdit version in order to make progress.

[jjstickel (Jonathan Stickel)]

I ran into another problem with gvedit. The download from the "releases" page on gitlab, https://gitlab.com/graphviz/graphviz/-/archive/2.47.0/graphviz-2.47.0.tar.gz is not quite the same as the official release on graphviz.org, https://gitlab.com/graphviz/graphviz/-/package_files/8183714/download. The former is the default using gitlab setup and does work for graphviz. Unfortunately, I don't know how to specify master_sites or distfilename for the latter, which has additional build files included for gvedit.

[Smattr (Matthew Fernandez)]

Sorry for delay; I didn’t actively monitor this ticket, assuming I would get email updates.

[The next paragraph discusses your URLs and you may want to just skip it and jump to the solution in the paragraph after that]

I think the first URL you posted is the “source code” link on the Gitlab releases page, right? That one is unhelpful and we would delete/omit it if we could. AFAIK Gitlab’s release-cli client we use to create our releases has no way to do this. What you’re after is what we confusingly refer to as the “portable source” which is the second URL you posted.

I think a sophisticated downstream consumer like Macports might actually be better off side-stepping the portable source (which is not as portable as its name implies), and cloning the Graphviz repository directly. We tag our releases so you would just have to clone tag 2.46.0 and refer to our CI¹ (which also side-steps the portable source). This will allow you to, e.g., enable the quartz dependencies that are disabled in the portable source. You have greater dependency requirements this way (Flex, Bison, …) but you get to build whatever you want with fewer assumptions.

¹ ​https://gitlab.com/graphviz/graphviz/-/blob/main/.gitlab-ci.yml#L77-112 and ​https://gitlab.com/graphviz/graphviz/-/blob/main/ci/build.sh#L47-53

[jjstickel (Jonathan Stickel)]

I got gvedit to configure, but then nothing was built (nothing to do for make all).

I also managed to build and install graphviz-gui, but it seems rather useless. I can edit an attribute once, and the graph in the viewer changes, but then any more attribute edits do not take effect.

So, my question is this: is it worth keeping the gvedit and graphviz-gui ports? They do not seem very useful, and keeping them around may hinder future updates to graphviz (as is happening now). Or at least remove gvedit. We can keep graphviz-gui for now since it at least builds and installs.

[ryandesign (Ryan Carsten Schmidt)]

Replying to Smattr:

Sorry for delay; I didn’t actively monitor this ticket, assuming I would get email updates.

You do if you Cc yourself.

I think a sophisticated downstream consumer like Macports might actually be better off side-stepping the portable source (which is not as portable as its name implies), and cloning the Graphviz repository directly.

MacPorts does not wish to clone repositories. MacPorts wishes to download (and mirror) source code tarballs.

This will allow you to, e.g., enable the quartz dependencies that are disabled in the portable source.

Why in the world would it not be possible to build with quartz support anymore by downloading the source code tarball? We've been able to do that before.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jjstickel:

I got gvedit to configure, but then nothing was built (nothing to do for make all).

I also managed to build and install graphviz-gui, but it seems rather useless. I can edit an attribute once, and the graph in the viewer changes, but then any more attribute edits do not take effect.

So, my question is this: is it worth keeping the gvedit and graphviz-gui portfiles? They do not seem very useful, and keeping them around may hinder future updates to graphviz (as is happening now). Or at least remove gvedit. We can keep graphviz-gui for now since it at least builds and installs.

I'm sorry that you find graphviz-gui useless. I don't and would like to keep it, and gvedit as well, unless upstream has discontinued these products.

[jjstickel (Jonathan Stickel)]

Replying to ryandesign:

I'm sorry that you find graphviz-gui useless. I don't and would like to keep it, and gvedit as well, unless upstream has discontinued these products.

Perhaps the version I built is not fully functional---I don't know because I haven't used it before. In any case, as a volunteer with a day job (as most Macports contributors and devs are, I know), I am willing and able to help with graphviz (the command-line tool), but not as much the GUIs. Someone more interested in those will need to contribute to keep them going.

[Smattr (Matthew Fernandez)]

MacPorts does not wish to clone repositories. MacPorts wishes to download (and mirror) source code tarballs.

OK, then maybe you really do want the Gitlab source code tarball instead of the portable source tarball. The maintainers do not support this work flow though, so working out the necessary steps might be challenging.

Why in the world would it not be possible to build with quartz support anymore by downloading the source code tarball? We've been able to do that before.

I do not know. But I note that the Graphviz macOS CI task ignores the portable source tarball created by a prior task and runs its own autogen and configure, ​https://gitlab.com/graphviz/graphviz/-/blob/main/ci/build.sh#L48-49:

./autogen.sh
./configure --prefix=$( pwd )/build --with-quartz=yes

As I said, most of the maintainers have no access to macOS so supporting it is mostly educated guesswork. Any suggestions for improving the CI or packaging setup are appreciated.

[jjstickel (Jonathan Stickel)]

I also have gvedit working now and created a ​PR.

[ryandesign (Ryan Carsten Schmidt)]

Replying to jjstickel:

I also have gvedit working now and created a ​PR.

Jonathan, thank you for the PR and for your work on this. I'll look into it and clean up any remaining issues.

Replying to Smattr:

• Graphviz still does the development releases, but I honestly don't know who is using them. The reality is that they are no more or less stable or tested than the "stable" releases, so I would simply like to move to a more frequent release cadence.

Matthew, Graphviz used to do even-numbered stable series (2.38.x, 2.40.x) and odd-numbered development series (2.39.x, 2.41.x), following the versioning scheme GNOME used until 2020. I see that Graphviz 2.47.0 was released and ​listed as a stable release. Can you confirm that this is accurate—that 2.47.0 is considered stable and that Graphviz no longer has a dedicated development versioning series? If that's true, and if it is planned that stable releases of Graphviz will occur more frequently, then I agree with getting rid of the graphviz-devel port and subports.

[Smattr (Matthew Fernandez)]

Ah I see, you're referring to the "development version" concept that Graphviz previously used. The current version numbers follow ​semantic versioning. The present notion of "development version" refers to the inter-release packages which are the ones I said I don't know who is using.

The even/odd distinction is not one Graphviz makes anymore. The 0.0.long_number ones in ​the Gitlab package registry are the unhelpful development versions, but every other x.y.z one is a stable release.

[ryandesign (Ryan Carsten Schmidt)]

Presumably updating graphviz will also resolve #63169.

[szhorvat (Szabolcs Horvát)]

I am very much looking forward to seeing a recent Graphviz in MacPorts. I hope this will happen soon.

And yes, including a native version of the GUI is important (I use it regularly).

[mascguy (Christopher Nielsen)]

Updated ticket to reflect latest release (2.48.0).

[mascguy (Christopher Nielsen)]

EDIT: I completely forgot about the pre-existing PR for graphviz. Never mind...

[mascguy (Christopher Nielsen)]

As part of the effort toward updating graphviz via Jonathan's PR, the Devel port (graphviz-devel) has now been updated to 2.48.0. And all three components - the base port, as well as both GUI subports - appear good as well.

Can you folks uninstall your non-Devel graphviz ports, and install the Devel versions? (graphviz-devel, graphviz-gui-devel, gvedit-devel) Thus far, everything looks good based on my local testing. The only caveat: The numerous graphviz variants have not been fully validated, so there may be some minor issues.

In any case, the more we can validate these ahead of time, the better. Please give them a try, and provide feedback.

[jarrodmillman (Jarrod Millman)]

I am happy to see this moving forward! FYI, graphviz 2.49.1 is the current stable release now: ​https://gitlab.com/graphviz/graphviz/-/releases

Here is the changelog: ​https://gitlab.com/graphviz/graphviz/-/blob/main/CHANGELOG.md

[mascguy (Christopher Nielsen)]

Updated open PR to 2.49.1, as well as graphviz-devel.

[jjstickel (Jonathan Stickel)]

In 564fd38ea3598b80f10c97146e28809313c22d70/macports-ports (master):

graphviz: update to 2.48.0

Closes: #63169
Closes: #62165
Closes: #61800
Closes: #59026
Closes: #58457