![]() ![]() Otherwise, seems sane.ĮDIT: In reflection, perhaps applying the above changeset as a unified diff from the pydot-feedstock is the appropriate solution after all. # Else, default to the standard Windows executable filetype.Ĭompletely untested and liable to implode your fingers like meaty blood sausages across the keyboard. If os.path.exists(os.path.join(sys.prefix, 'conda-meta')): # Anaconda Graphviz packages require batch file wrappers. # wrappers specific to Anaconda Graphviz packages. # If this is an Anaconda-based Python interpreter, default to the batch file If os.name = 'nt' and prog in default_names and not os.path.splitext(prog): # If this is a Graphviz executable under Windows with no filetype. If os.name = 'nt' and prog in default_names: A best-of-breed solution might edit lines 1826-1828 of the Dot.create() method of the pydot module in their main development branch as follows: If we open a similar issue coupled with a minimal-length pull request, I'm reasonably confident we can ram a sensible changeset into the underlying pydot codebase without the need for fragile feedstock tomfoolery that no one wants to maintain. I suspect we can probably do better here. I hate doing that, which may explain why my overlay is bit-rotting. They typically have to be manually recreated on every version bump. Maintaining unified diffs in perpetuity against a moving target is error-prone at best. The disadvantage, of course, is that it's fragile. ![]() As a Gentoo overlay maintainer, I'm painfully familiar with the approach. That's exactly what that feedstock is doing. You externally patched the xflr6/graphviz codebase from the python-graphviz-feedstock recipe at installation time, didn't you? bat) yielded only this closed unresolved issue. Do you happen to have a link to the pull request that patched Windows-specific conda support into xflr6/graphviz? Grepping the repository for suspected keywords (e.g., conda. I'm happy to lend a hand with that, actually. We could patch it like we did with python-graphviz. but this sounds like a volunteer match made in GitHub heaven: I may be biased, Whenever someone says that, they're biased. the principal maintainer of pydot, is congenial, actively involved, and an all-around jolly good fellow. That said, I've personally contributed pull requests to both pydot and Network (on behalf of pydot). ![]() Is that ok for you? I think it's better than Hack it because it's less brittle and prone to be broken by a future update in conda packages. I submitted a PR to python-graphviz to detect and use conda's Graphviz binaries, so I do could the same for pydot. What would you recommend downstream packages requiring Graphviz (like, say, our multiphysics simulator) do in the meanwhile? Anaconda uses conda-forge feedstocks as their upstream for conda recipes since Anaconda 5.0. Once the conda-forge Graphviz feedstock is sanitized, would backporting those improvements into the official Graphviz package be feasible? If Windows compilation is on the table for 2.40, I'd expect the same time again. Last time it took me about three weeks of hard work to compile 2.38 on Linux/macOS and repackage it on Windows. I don't work for Anaconda anymore, so I can't contribute to fix this in my work time. What do you need from the community to get this gangrenous limb amputated? In fact, they agreed with my decision of repacking its binary installer.īesides, there you'll have to contribute your time to build Graphviz on Windows too, so there's no much of a difference here or thanks for chiming in and trying to find a solution to this. I'm saying that we don't have the time to properly build it right now, and that, since a better build system is on its way, it's better for us to wait for it. I'm ok if you say that the conda repo doesn't care about providing a properly built graphviz, which means I can just give up on the main anaconda repo. If not, we'll wait until the next Graphviz release with CMake support is available. I meant that if you want to help us by spending your time on building Graphviz from sources on Windows, then that's very welcome. PR welcome is very different to "this issue is fixed". Sure, we're breaking the pip package, but we also fixed that problem in our end (which is very similar to what Debian/Fedora/Suse, etc do when they decide to modify something for internal reasons). The problem is breaking an existing package by using a hack in conda in a different package. We're providing the same package under the conda ecosystem. Whereas the Python package is pure Python and can be installed perfectly well with pip. We don't have time to properly build it on Windows, sorry. Yes, and installing a properly built graphviz is exactly what conda can do.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |