search

ContinuumIO / anaconda-issues

Anaconda issue tracking
648 stars 224 forks source link

graphviz package doesn't add executable to PATH on windows #1666

Closed kalefranz closed 7 years ago

kalefranz commented 7 years ago

From @amueller on May 4, 2017 22:34

The graphviz dot executable is installed to <anaconda>/Library/bin/graphviz/ (I think, don't have a machine here to double check - but there's definitely a graphviz sub-folder). But this folder is not added to the executable search path. That means that it can not be used basically, and using the python graphviz package fails. I just manually fixed this issue at around 10 laptops in my workshop :-/ doing !set PATH=PATH;C:\path\to\anaconda\Library\bin\graphviz\ fixed it.

Copied from original issue: conda/conda#5227

kalefranz commented 7 years ago

activate on windows should absolutely be adding Library\bin to PATH.

https://github.com/conda/conda/blob/4.2.16/conda/cli/activate.py#L73

How are you accessing a command line on windows? In what terminal? How is the initialization of the terminal being configured?

If you're using the Anaconda Prompt that's a cmd.exe shell, then activate root should be called automatically for you. If you're just using plain cmd.exe, then you might have to call it yourself. I don't know what all the Anaconda installer adds to PATH by default, but I know there's a push to add even less.

CC @mingwandroid

kalefranz commented 7 years ago

From @amueller on May 4, 2017 23:37

The executable is not in bin, though, it's in a graphviz subfolder.

I was trying to avoid using any command line and just ran things inside the notebook (like !set), figuring that has the best chances to be in the right environment. And I don't think jupyter was started from the command line, more likely from the start menu.

kalefranz commented 7 years ago

From @mingwandroid on May 4, 2017 23:43

If you can move this to Anaconda-issues and assign it to me please do @kfranz.

Also, do you think it would be possible to setup an issues template so that people are forced to think about whether the bug they are reporting concerns conda or whether it concerns AD (or navigator or Spyder or constructor etc)? I think it could save quite a bit of your time if so.

kalefranz commented 7 years ago

The executable is not in bin, though, it's in a graphviz subfolder.

Oh I totally missed that. My mistake.

do you think it would be possible to setup an issues template

I've been considering that for quite a long time. I'm not a fan of the github implementation, but I think it might just be time.

ccordoba12 commented 7 years ago

@amueller said

I just manually fixed this issue at around 10 laptops in my workshop :-/ doing !set PATH=PATH;C:\path\to\anaconda\Library\bin\graphviz\ fixed it.

There's no need to do that. We create batch scripts in Library\bin for every executable present in Library\bin\graphviz, so you can easily call, for example, dot from the command line without problems.

@amueller, is not that the case for you? I mean, are you able to see those batch scripts in your installation or not?

amueller commented 7 years ago

@ccordoba12 Sorry I can't check that. I don't use windows myself. I had about 10 people in my workshop on Wednesday that all had this exact problem. Do you have a windows computer you could check this on? They all used the most current version of anaconda and just installed graphviz.

ccordoba12 commented 7 years ago

How are they calling graphviz? Directly in the console or through a Python package?

amueller commented 7 years ago

through the graphviz python package. (pip install graphviz)

ccordoba12 commented 7 years ago

Ok, I thought so. I fixed this problem a couple of months ago, but (unfortunately) packages for Windows with my fix were not created (although they were created for Linux and Mac). I'll talk to @mingwandroid about this.

@amueller, in the future you need to tell your students to run

conda install python-graphviz

instead of

pip install graphviz

to get these bindings, which also work with conda's Graphviz package.

amueller commented 7 years ago

alright, will do. thanks.

ccordoba12 commented 7 years ago

Packages for python-graphviz on Windows are now available in our channels.

Thanks for your patience.

amueller commented 7 years ago

Thanks! Does using the conda graphviz executable with the pip-installed graphviz python library work? If the path is set correctly, there shouldn't be a problem, right?

ccordoba12 commented 7 years ago

Does using the conda graphviz executable with the pip-installed graphviz python library work?

No, it doesn't.

If the path is set correctly, there shouldn't be a problem, right?

No, that's not correct. Adding Library\bin\graphviz to PATH would make Spyder and matplotlib to crash because Graphviz comes with its own set of (incompatible) Qt and other libraries. That's why we added them to its own subdirectory inside Library\bin instead of adding them directly to Library\bin.

So, please don't do it.

amueller commented 7 years ago

Oh wow... but couldn't that be fixed within the graphviz build?

So, please don't do it.

What? Adding it to the path or using the pip graphviz? Not being able to use the standard method of interacting with dot seems like a pretty big issue. Requiring a specific configuration in the python graphviz means that there is a tight coupling between these packages when there shouldn't be. How about networkx? That also uses the dot executable, right? And I think there's many more packages that do.

amueller commented 7 years ago

Can you please reopen the issue? This doesn't really seem to be solved.

ccordoba12 commented 7 years ago

What? Adding it to the path or using the pip graphviz?

Neither of those. Adding Library\bin\graphviz to PATH could break Spyder and Matplotlib, and the pip graphviz packages are not compatible with the graphviz package provided by conda.

To be clarify even further:

  1. conda install graphviz installs the C graphviz executables and libraries (e.g. the dot executable).
  2. pip install graphviz installs one of the Python bindings for Graphviz (the one used by Dask).
  3. conda install python-graphviz installs the same package as pip install graphviz, but patched to work with conda's Graphviz C package.

Requiring a specific configuration in the python graphviz means that there is a tight coupling between these packages when there shouldn't be.

There's no additional configuration, you just need to run

conda install python-graphviz

instead of

pip install graphviz

(as I said above).

How about networkx? That also uses the dot executable, right? And I think there's many more packages that do.

I don't know, but nobody has complained about it. We'll look into it if somebody reports an issue.

If there are more packages that use dot, they need to change from

subprocess.call(['dot'])

to

subprocess.call(['dot'], shell=True)

for Windows (which is a good practice anyway because it prevents opening a cmd.exe window).

Can you please reopen the issue? This doesn't really seem to be solved.

This is solved. We can't add Library\bin\graphviz to PATH because it would be break all packages that depend on Qt, sorry.

amueller commented 7 years ago

I meant configuration inside the python graphviz-package. I wasn't sure what you needed to change to make it run with the conda build of graphviz - it seems you need to change the call to subprocess.call.

This is solved. We can't add Library\bin\graphviz to PATH because it would be break all packages that depend on Qt, sorry.

Why does graphviz need to be built against a different Qt and not the Qt that Spyder etc use?

ccordoba12 commented 7 years ago

We don't build Graphviz on Windows, we simply repackage its binary installer as a conda package. Since the installer comes with several Qt libraries, we needed to resort to the trick of moving its files to Library\bin\graphviz and creating batch scripts for its executables.

amueller commented 7 years ago

Ok, so the problem is in not rebuilding graphviz to fit your environment. That seems a pretty solvable problem...

amueller commented 7 years ago

Should the change to subprocess.call go upstream in the Python graphviz library?

ccordoba12 commented 7 years ago

Ok, so the problem is in not rebuilding graphviz to fit your environment. That seems a pretty solvable problem...

PRs are welcome. Graphviz is very complex package and it's build process on Windows is a mess (I've heard they are planning to move to CMake for its next version, so that would make things very easy for us).

Should the change to subprocess.call go upstream in the Python graphviz library?

Please see https://github.com/conda-forge/python-graphviz-feedstock/pull/6. I don't know if the author would accept it.

In any case, I really don't understand what's the problem with using conda install python-graphviz instead of pip install graphviz. This is a real instance to show people that conda is not a pip replacement.

amueller commented 7 years ago

Yes, and installing a properly built graphviz is exactly what conda can do. Whereas the Python package is pure Python and can be installed perfectly well with pip. The problem is breaking an existing package by using a hack in conda in a different package.

PR welcome is very different to "this issue is fixed". It's likely messy but there's a pretty clear fix, and as long as graphviz doesn't provide an executable that can be used with the stock Python package I'd consider it broken. Though really it should be considered broken as long it can not be added to "PATH".

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, and I'll open an issue on conda-forge.

Sent from phone. Please excuse spelling an

ccordoba12 commented 7 years ago

Yes, and installing a properly built graphviz is exactly what conda can do.

We don't have time to properly build it on Windows, sorry.

Whereas the Python package is pure Python and can be installed perfectly well with pip.

We're providing the same package under the conda ecosystem.

The problem is breaking an existing package by using a hack in conda in a different package.

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).

PR welcome is very different to "this issue is fixed".

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. If not, we'll wait until the next Graphviz release with CMake support is available.

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.

I'm not saying that. 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.

and I'll open an issue on conda-forge.

I maintain Graphviz in conda-forge too. In fact, they agreed with my decision of repacking its binary installer.

Besides, there you'll have to contribute your time to build Graphviz on Windows too, so there's no much of a difference here or there.

ccordoba12 commented 7 years ago

Again, this clearly shows (in my humble opinion) that conda is not a pip replacement. The sooner people realizes this simple fact, the better for all of us, I think.

amueller commented 7 years ago

I'm not sure what you mean by that. They clearly serve different purposes. I'm not aware of other places where a conda package breaks a depending package if it's installed by pypi, but maybe I'm ignorant. If this is happening in other places that's pretty concerning, though. I'm pretty sure I can still download most software and built the stock version on a debian or redhat machine without needing to modify (apart from configuration).

I'm not saying that.

But earlier you said

This is solved.

I totally appreciate the fact that you don't have time for it. But "I don't have time to solve this", "This is solved" and "This is out of scope" are very different to me. Initially you said "This is solved", now you say "I don't have time to solve it". But I feel you are also implying "This is out of scope" by closing the issue and because of your remark on pip vs conda.

amueller commented 7 years ago

By your logic, there might become a day when stock scikit-learn breaks on conda because you hacked numpy, and only the conda-shipped scikit-learn works. That would basically be the same thing in terms of breaking dependencies.

If that happens, I will uninstall conda, and I hope everyone else does, too.

ccordoba12 commented 7 years ago

I'm not aware of other places where a conda package breaks a depending package if it's installed by pypi, but maybe I'm ignorant

pyqt5 is another clear example. It's almost impossible for us to make it work under Anaconda.

But earlier you said

This is solved.

Your initial issue was about adding Library\bin\graphviz to PATH, something I told you we can't do, and also pointed out to a simple solution: conda install python-graphviz. That's why I consider it solved, as Wont fix if you prefer.

Your second issue (building Graphviz from sources on Windows) is not the main one here. Of course that's not solved, but we hope to solve it in the future. Please open a new issue about it if you feel the need for it.

amueller commented 7 years ago

Building conda on windows is a solution to exactly the problem of adding the executable to the path and fixes the "wont fix". So you're asking me to open an issue that solves an issue that is "wont fix"? I can rename it "conda installs binary incompatible graphviz" if you like...

Anyhow I already wasted enough time on this, this just emphasizes the need to come up with a solution for my class that doesn't use graphviz.

ccordoba12 commented 7 years ago

By your logic, there might become a day when stock scikit-learn breaks on conda because you hacked numpy, and only the conda-shipped scikit-learn works. That would basically be the same thing in terms of breaking dependencies.

There are some things we need to do in conda to accommodate packages from different languages (remember that conda is not just for Python) and make them work on different operating systems as seamlessly as we can.

I don't know about any issues with scikit-learn, but I certainly know some with stock Matplotlib (not because we hack it, just because we want to make it work better for our users), but we're trying to reach an agreement with Matplotlib devs.

ccordoba12 commented 7 years ago

So you're asking me to open an issue that solves an issue that is "wont fix"

Ok, I'll open it myself. Happy?

I just want to preserve this issue as it was originally posted and discussed in case someone else wants to propose the same solution.

amueller commented 7 years ago

ok

ccordoba12 commented 7 years ago

Anyhow I already wasted enough time on this, this just emphasizes the need to come up with a solution for my class that doesn't use graphviz.

I wasted more, I just wanted to avoid Graphviz break Spyder on Windows and ended up being the Graphviz maintainer everywhere :-)

But hey, I just don't get you: what's the problem with conda install python-graphviz? This is a solution we didn't come up with lightly. It was something agreed upon between conda-forge and Continuum after a very lengthy discussion:

https://github.com/conda-forge/staged-recipes/pull/568

leblancfg commented 7 years ago

For the record, I needed to call graphviz executables from the command line, and dot wasn't showing in my PATH. I'm running "Git Bash" for Windows, i.e. Cygwin, and all other CLI tools I've installed from conda can be called directly after installation from this shell. I was getting:

bash: dot: command not found

After some checking around, I realized they're showing up in CMD.exe fine, however! So should be fine for like 90% of Windows users.

If you're using Cygwin though, a handy way for it to show up in your PATH is the following under the root level of the same drive your conda installation is in:

export PATH=(find -maxdepth 10 -name dot.exe | grep -v pkgs):$PATH

Which will compute to export PATH=/c/Users/path/to/Anaconda3/Library/bin/graphviz:$PATH and let you call dot, neato, etc. directly from your Cygwin shell.

ImtiazKhanDS commented 6 years ago

If you want to display the tree graph using export_graphviz object , the jupyter notebook path from where you are opening should contain the exe files of graphviz bin folder in the same directory

mehmet-sahinoglu commented 6 years ago

Hi, Graphviz 2.38 installation did not add to path. I had to add manually. (Windows 10 Home Edition) Just FYI.

Deepanshu8391 commented 6 years ago

Hey, I have followed the following steps and it worked fine for me. 1 . Download and install graphviz-2.38.msi from https://graphviz.gitlab.io/_pages/Download/Download_windows.html

2 . Set the path variable (a) Control Panel > System and Security > System > Advanced System Settings > Environment Variables > Path > Edit (b) add 'C:\Program Files (x86)\Graphviz2.38\bin'

leycec commented 6 years ago

@ccordoba12 Thanks for your tireless efforts with the thankless chore that is Anaconda-Graphviz-Windows integration. In light of corresponding work (e.g., this recent issue, this older issue) by both you and @jakirkham at the conda-forge Graphviz feedstock, would reopening this issue be feasible?

If not, I sympathize. No one likes a necrobump. In that case, would someone mind opening a new issue on the same topic? If there are no other takers, I'll begrudgingly do it. Emphasis on begrudgingly.

What's This All About, Anyway?

For those following along at home, all Graphviz packages for Anaconda currently fail to add Graphviz binaries to the %PATH% under Windows due entirely to these packages merely rebundling the stock Graphviz installer for Windows. Refactoring these packages to instead rebuild Graphviz against the Anaconda toolchain provided by either the default or conda-forge channel should permanently resolve this issue.

That's optimism for you.

So, Why Haven't You Done That Yet?

Because doing so requires a sane make process. Prior GraphViz versions only provided an autotools-based make process. While adequate (but horrible) under POSIX-compatible platforms like macOS and Linux, autotools famously faceplants under Windows. Notably, autotools fails to support the most popular Windows compiler. If you were thinking "It's Visual Studio, isn't it?", you were right. This is why we can't have nice things.

GraphViz 2.40.1 purports to provide a sane make process: CMake. In fact, the official Windows binaries for GraphViz 2.40.1 appear to have been built entirely with CMake rather than autotools. Well, maybe. I'm entirely external to this debate. (Read: I regurgitate what other smarter people say.)

In conda-forge/graphviz-feedstock#21, @jakirkham confidently asserts that is the case. If True, then Rejoice... for a resolution is surely nigh at hand!

So, Why Hasn't Anyone Else Done That Yet?

I don't know, actually. Everyone was filled with righteous fury about this a year ago, yet little to no actual progress has been made on the malignant tumour – despite the newest stable release of GraphViz claiming to resolve the blocker on our end (i.e., the insane build system).

My questions to @ccordoba12 and @jakirkham are many-fold:

I'm leaning towards Hack it., 'cause that's just how we roll.

kalefranz commented 6 years ago

We updated graphviz not too long ago in defaults, and at the time, I was hoping to build graphviz from source on windows. It ultimately didn't end up happening because their build system configuration really doesn't work on windows in their last stable release for unix, and that's probably why their last stable release on windows is a couple versions behind their last stable release on unix. Still, the last unix stable release was in 2016. There's been plenty of work in the repository, and much of it on their build configuration; I don't know the details of the project and why they are cutting releases. So... that's the history as I remember.

the official Windows binaries for GraphViz 2.40.1 appear to have been built entirely with CMake

Where are these official binaries located?

jakirkham commented 6 years ago

Does the pydot package work? If so, great. If not, we could patch it like we did with python-graphviz. Admittedly not the ideal solution, but I think this more feasible given your timeline.

There was a lot of work in graphviz (upstream) to use CMake, but much of it remains untagged. Pinged the issue with them ( https://gitlab.com/graphviz/graphviz/issues/1219 ) again to check the status.

ccordoba12 commented 6 years ago

@leycec, thanks for chiming in and trying to find a solution to this. My answers:

What do you need from the community to get this gangrenous limb amputated?

I don't work for Anaconda anymore, so I can't contribute to fix this in my work time. Last time it took me about three weeks of hard work to compile 2.38 on Linux/macOS and repackage it on Windows. If Windows compilation is on the table for 2.40, I'd expect the same time again.

Once the conda-forge Graphviz feedstock is sanitized, would backporting those improvements into the official Graphviz package be feasible?

Sure. Anaconda uses conda-forge feedstocks as their upstream for conda recipes since Anaconda 5.0.

What would you recommend downstream packages requiring Graphviz (like, say, our multiphysics simulator) do in the meanwhile?

  • we require pydot

I can help you with that. I submitted a PR to python-graphviz to detect and use conda's Graphviz binaries, so I do could the same for 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.

leycec commented 6 years ago

Does the pydot package work?

Sadly, no. That said, I've personally contributed pull requests to both pydot and Network (on behalf of pydot). @johnyf, the principal maintainer of pydot, is congenial, actively involved, and an all-around jolly good fellow. I may be biased, Whenever someone says that, they're biased. but this sounds like a volunteer match made in GitHub heaven:

we could patch it like we did with python-graphviz.

:sun_with_face:

I'm happy to lend a hand with that, actually. 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, .bat) yielded only this closed unresolved issue.

Or... don't tell me. You externally patched the xflr6/graphviz codebase from the python-graphviz-feedstock recipe at installation time, didn't you? </sigh>

Oh, boy. That's exactly what that feedstock is doing. As a Gentoo overlay maintainer, I'm painfully familiar with the approach. The disadvantage, of course, is that it's fragile. Maintaining unified diffs in perpetuity against a moving target is error-prone at best. They typically have to be manually recreated on every version bump. I hate doing that, which may explain why my overlay is bit-rotting.

I suspect we can probably do better here. @johnyf is amenable to reason. Don't quote me on that. I'm sometimes wrong about people. (Horribly, horribly wrong.)

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. 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:

#FIXME: Modify this conditional...
if os.name == 'nt' and prog in default_names:
    if not prog.endswith('.exe'):
        prog += '.exe'

#FIXME: ...to resemble this.
# If this is a Graphviz executable under Windows with no filetype...
if os.name == 'nt' and prog in default_names and not os.path.splitext(prog)[1]:
    # If this is an Anaconda-based Python interpreter, default to the batch file
    # wrappers specific to Anaconda Graphviz packages. See:
    # * https://stackoverflow.com/a/47610844/2809027 for Anaconda detection.
    # * https://github.com/ContinuumIO/anaconda-issues/issues/1666 for why
    #   Anaconda Graphviz packages require batch file wrappers.
    if os.path.exists(os.path.join(sys.prefix, 'conda-meta')):
        prog += '.bat'
    # Else, default to the standard Windows executable filetype.
    else:
        prog += '.exe'

Completely untested and liable to implode your fingers like meaty blood sausages across the keyboard. Otherwise, seems sane.

EDIT: In reflection, perhaps applying the above changeset as a unified diff from the pydot-feedstock is the appropriate solution after all. The advantage there is fine-grained control: when this underlying issue is eventually resolved, that patch can simply be removed from that feedstock without concern over undoing a pydot pull request and releasing a new stable release of pydot. In that case, the above changeset could be reduced to simply:

#FIXME: Modify this conditional...
if os.name == 'nt' and prog in default_names:
    if not prog.endswith('.exe'):
        prog += '.exe'

#FIXME: ...to resemble this.
if os.name == 'nt' and prog in default_names and not os.path.splitext(prog)[1]:
    prog += '.bat'

Yeah. That's probably saner.

I don't work for Anaconda anymore, so I can't contribute to fix this in my work time.

Absolutely. I sympathize with your unpaid plight. In my case, I'm simply tired of this not working. Since personal frustration >>> chronic laziness, I might now be willing to actually do something about this. If I do, it will only be with bared teeth and a bitter heart, of course.

Last time it took me about three weeks of hard work to compile 2.38 on Linux/macOS and repackage it on Windows. If Windows compilation is on the table for 2.40, I'd expect the same time again.

My Gods. So, what you're saying is: "This will never be properly resolved within the lifetime of our Universe." I appreciate that forward-thinking candour. Unflinching pessimism with respect to setuptools and pip is what got us this far, after all.

Anaconda uses conda-forge feedstocks as their upstream for conda recipes since Anaconda 5.0.

Wow. Really? That's awfully intelligent of them. I'm all for simplifying everyone's life. (Especially mine.)

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.

Yup. I'd be delighted if someone(s) else would maintain my hackery on my behalf. Please do this.

Incidentally, did I mention that you and @jakirkham and @kalefranz are awesome and beautiful people?

kalefranz commented 6 years ago

@leycec You made me laugh. More than once. After a long day, thanks for that :)

dloperab commented 6 years ago

What? Adding it to the path or using the pip graphviz?

Neither of those. Adding Library\bin\graphviz to PATH could break Spyder and Matplotlib, and the pip graphviz packages are not compatible with the graphviz package provided by conda.

To be clarify even further:

  1. conda install graphviz installs the C graphviz executables and libraries (e.g. the dot executable).
  2. pip install graphviz installs one of the Python bindings for Graphviz (the one used by Dask).
  3. conda install python-graphviz installs the same package as pip install graphviz, but patched to work with conda's Graphviz C package.

Requiring a specific configuration in the python graphviz means that there is a tight coupling between these packages when there shouldn't be.

There's no additional configuration, you just need to run

conda install python-graphviz

instead of

pip install graphviz

(as I said above).

How about networkx? That also uses the dot executable, right? And I think there's many more packages that do.

I don't know, but nobody has complained about it. We'll look into it if somebody reports an issue.

If there are more packages that use dot, they need to change from

subprocess.call(['dot'])

to

subprocess.call(['dot'], shell=True)

for Windows (which is a good practice anyway because it prevents opening a cmd.exe window).

Can you please reopen the issue? This doesn't really seem to be solved.

This is solved. We can't add Library\bin\graphviz to PATH because it would be break all packages that depend on Qt, sorry.

It works...installing "conda install graphviz", "pip install graphviz" and "conda install python-graphviz" in Windows + Anaconda.

EelcoHoogendoorn commented 6 years ago

Boy I feel bad pointing this out; but I just had this OSError:pydotfailed to call GraphViz.Please install GraphViz happen. Thats me trying to save a graph from keras on OSX.

The funny thing is; it used to work just fine up until recently. I tried some clueless flailing like replacing graphviz with python-graphviz, and that does not change anything.

So yeah, whatever happened in the dependency chain, seems the problem just got worse. Hopefully have time tomorrow to pinpoint with which package version update things went haywire.

ciurlaro commented 6 years ago

Ok, I thought so. I fixed this problem a couple of months ago, but (unfortunately) packages for Windows with my fix were not created (although they were created for Linux and Mac). I'll talk to @mingwandroid about this.

@amueller, in the future you need to tell your students to run

conda install python-graphviz

instead of

pip install graphviz

to get these bindings, which also work with conda's Graphviz package.

Sorry for Caps. THANK YOU MAN.

I spent 2 days to find out what the problem was and this solved it! Thank you so much!

I didn't understand why it worked by the way.

osolo98 commented 6 years ago

don't know if anybody else is still having a problem with this, I did try adding the environment path(s), didn't work. but the only thing that worked for me was adding these 2 lines in Spyder

import os os.environ["PATH"] += os.pathsep + 'C:/Anaconda3/Library/bin/graphviz'

Deusami commented 6 years ago

ok guys, it still doesn't work. (win10, anaconda, jupyter notebooks)

I have tried uninstalling I have tried installing python-graphviz (on conda)

I want to go back to dos and Fortran.

Need pydot and graphviz.

arrgggghhhh.....

mingwandroid commented 6 years ago

Did you activate your environment?

Deusami commented 6 years ago

Specifically what are you asking. I am in anaconda on a jupyter notebook. I have installed python-graphviz. I have the following statements in my code:

from sklearn.externals.six import StringIO
from IPython.display import Image
from sklearn.tree import export_graphviz import graphviz import pydotplus

I have added crap to my path (specifically:

set PATH=PATH;C:\Program Files (x86)\Graphviz2.38\bin set PATH=PATH;C:\users\user\anaconda3\Library\bin\graphviz\

(yes, I know I shouldn't have done the last one but I'm not completely sure how to undo it now).

I am old. I am tired. This is homework and it's not going well.

Amulash commented 5 years ago

I installed graphviz using pip and now spyder crashed in windows !!! I'm using jupyter now but how to set up the executables in path ??

Error is shown below : ~\Anaconda3\lib\site-packages\keras\utils\vis_utils.py in _check_pydot() 27 except OSError: 28 raise OSError( ---> 29 'pydot failed to call GraphViz.' 30 'Please install GraphViz (https://www.graphviz.org/) ' 31 'and ensure that its executables are in the $PATH.')

OSError: pydot failed to call GraphViz.Please install GraphViz (https://www.graphviz.org/) and ensure that its executables are in the $PATH