Besides that, don’t forget its IronPython you are using.
There is another Python script component downloadable which is based on standard Python, but because of this it cannot work with rhino objects since it cannot handle .dotnet libraries.
There’s nothing else in the script(import networkx was in line 4), I manage to “import” the module by correcting the path, but it throws other errors that i believe are not that easy to fix. Yes, I have try the CPython Component and it works, but it doesn’t manage lists and trees(output of the component) in the same way as the GhPython, so the output has to be formated. This are the new Errors:
import sys
sys.path.append("C:/Python27/Lib/site-packages/")
import networkx
Runtime error (ImportException): Cannot import name all_pairs_node_connectivity
Traceback:
line 76, in <module>, "C:\Python27\Lib\site-packages\networkx\algorithms\__init__.py"
line 26, in <module>, "C:\Python27\Lib\site-packages\networkx\generators\classic.py"
line 6, in <module>, "C:\Python27\Lib\site-packages\networkx\generators\__init__.py"
line 114, in <module>, "C:\Python27\Lib\site-packages\networkx\__init__.py"
line 4, in script
I managed to import networkx library (version 2.0.dev_20160927182259) into rhino6 and gh earlier today without having numpy and scipy.
I placed the networkx folder into C:\Program Files\Rhino 6\Plug-ins\IronPython\Lib\site-packages\networkxrkx, typed in _EditPythonScript command went to Options, under Tools tab, and added the same path.
Hopefully this works for you and others, and below is the thread I was on (others’ comments may be helpful):
That’s terrific news, thanks for the update! I wonder if this compatibility is because Rhino 6 ships with a newer version of IronPython (in which these dependency issues have been resolved, as I recall the decorators module was one issue). Anywho, IronPython in Rhino 5 is version 2.7.3:
Yeah, if you also have Rhino 5 installed on your system, maybe try to see if you can run in there as well. Would be useful to know (i.e. if it’s this particular version of networkx, or, indeed the newer version of IronPython that is making things work).
so i opened up rhino5 32bit and gave it a try:
the version of ironpython is 2.7.5 (32-bit),
and it works with networkx version 1.5, but not with the 2.0 i was working with in rhino6.
so, in conclusion, although the versions are the same, i guess 32-bit only works with lower versions of networkx…?
Hi, that’s good news, has anyone try the igraph library with the GHPython?, it seem to be bigger and a lot faster than networkxs, specially for calculation like centrality, betweeness…it solve like 15 times faster than networkxs, so if you have a very big graph(2000k nodes) that’s pretty much the only real solution in python, for windows, there’s other library that’s call graph-tools that apparently is faster 2 times igraph, I couldn’t find any package for windows.
Pretty sure it depends on C++ on the backend, so probably not straightforward to implement using GHPython (although one can probably go through ctypes ala this ShapeOp implementation). Or use one of the CPython Grasshopper plugins. There are also .NET graph libraries out there, if performance is an issue (i.e. implement them in a compiled C# plugin).
Hi Anders, this is great! It doens’t seem all that different from what I’ve done for networkx 2.0 in rhino 6. Could we basically implement other libraries following this process? Am I missing something?
There are quite a few threads here and on the old GH forum about this, but basically:
Since IronPython is written in C#, you can use most (maybe all?) .NET libraries directly (i.e. how we can implement RhinoCommon, Kangaroo, the Grasshopper API etc. in GHPython).
Most pure (i.e. written in straight up Python) Python modules should work in IronPython (there may be some compatibility issues here and there with versioning i.e. the networkx issues).
CPython modules that depend on e.g. C++, Fortran etc. on the backend (i.e. numpy, scipy etc.) won’t run in IronPython (or, not in any straight forward manner, see the now dead Enthought numpy project). That said, there are ways around this (i.e. to use one of the CPython components, or implement the C++ library directly), but these can be clunky and quite non-trivial solutions.
I was just a bit confused by the ShapeOp example you shared because the process didn’t seem all that different from implementing the networkx library.
Also, regarding CPython, what about this:
Since I’ve only implemented numpy, scipy, and networkx so far, it’s good to know what the possibilities and limitations are going down the road…
That example implements the ShapeOp C++ library directly using the OOTB ctypes Python module (which is also available in IronPython) to make, well, C types (see for instance this line). So in that sense, it is very different from implementing networkx (which is a pure Python module), even though they may look superficially similar.
In Rhino/GHPython (notably 64 bit)?
I haven’t tried it yet, so can’t really comment. Note that there is also this project: