Distribute Revit/Dynamo with The (Iron)Python Standard Library?

python

#1

Hi All,

First-time poster here, many-time poster over on the Rhino/Grasshopper forum(s).

I am currently familiarising myself with the various Python interfaces and API’s available in Revit (using the Dynamo Python node and the revitpythonshell). Coming from the Grasshopper GHPython component, I’ve been experiencing quite a few small and not so small hiccups (specifically: no console/print out, no run/test button/shortcut, no auto-indentation, tabs instead of spaces, poor intellisense, the editor moves on close/open etc). Some of these issues do appear to currently be being addressed, which is just terrific to see.

That said, I have not come across any initiatives that address the issue of importing the (Iron)Python Standard Library. I am aware that one may install and reference this manually within the script. However, this not only requires anyone using the script to download/install IronPython (which is cumbersome and error prone), but may also cause more severe versioning and compatibility issues. One could also argue that anyone developing in Python could be expected to expect to import modules from the standard library :wink:

Anywho, long story short: Perhaps you (not sure whom I’m addressing here, my bad) could distribute the standard library with Revit and hardcode the path to it, similarly to how McNeel manages it with Rhino/Grasshopper.

Cheers and best,

Anders


#2

I’ve been made aware that Revit/Dynamo autonomously installs IronPython 2.7 to C:\Program Files (x86)\IronPython 2.7. Meaning that it (in a way) does distribute with the IronPython Standard Library. While that does negate my issue regarding having the end-user of a script implementing the Standard Library install IronPython, is does raise two new ones (the first being rather serious and somewhat unacceptable IMO):

  1. Referring to the potential compatibility issues mentioned above, allowing Revit/Dynamo to install system-wide software that may break the IronPython interpreter of other applications, is highly problematic and should be revised (I’d suggest looking to McNeels distribution model here).

  2. Seeing as how Revit/Dynamo does distribute with the Standard Library, its IronPython scripting environments really should have a path to this library hardcoded, as this is how most (if not all) other standard Python distributions are set up (including the IronPython distribution itself that Revit/Dynamo installs!).

Anywho, don’t mean to bust in here and make a big fuss, but these concerns do strike me as being counter to (certainly my) incentive to integrate IronPython within Revit/Dynamo pipelines.

On a side note: Would it be advisable to raise these concerns straight on the Dynamo GitHub instead?

Edit: Started an Issue here.

Best,

Anders


#3

To demonstrate how the current Revit/Dynamo IronPython distribution model can affect other applications, here are two real-world examples:

  1. https://discourse.mcneel.com/t/rhino-6-wip-grasshopper-python-does-not-load-os-module/37877/15?u=andersdeleuran

  2. https://github.com/ladybug-tools/ladybug-dynamo/issues/34

I realise that I’m new and may not know how things work around here. But I’d hate to be barking into the air like a mad man, so any hint that these (arguably severe) issues have been seen by developers would be appreciated!

Best,

Anders


#4

Hi @AndersDeleuran,

Perhaps @Zach_Kron, @Racel_Williams or @Michael_Kirschner2 can help with your query :slightly_smiling_face:


#5

@AndersDeleuran thanks for this thread and the issue as well.
@Zach_Kron and @Racel_Williams we should talk about this. It causes problems with PyRevit as well and there are solutions. We have not changed our python distribution method or version since we started distributing it. (I think).


#6

@AndersDeleuran can you say a bit about McNeels’s ironPython distribution approach?


#7

Absolutely,

Rhino ships with its own IronPython distribution here:

With the Standard Library within the Lib folder:

And the GHPython component (being a standard Grasshopper assembly called a .gha, which is essentially a .dll) goes here:

I’m not entirely sure if there is more to it and how this is all wired up within the Rhino source itself, but the GHPython component source is available here (for Rhino 5 at least, not sure if the new Rhino 6 source is open):

As you can see from the screenshot in my initial post, there is also the standard Rhino (i.e. non-grasshopper specific) EditPythonScript editor from within which one can hardcode module search paths that will also work in GHPython (in addition to the default ones that include the Standard Library path and some Rhino-specific modules).

On a side note: The GHPython component also comes hardcoded with references to the RhinoCommon and Grasshopper API’s (i.e. clr.AddReference to the two relevant assemblies). I’m still entirely new to Revit/Dynamo, but perhaps this might also make sense for commonly implemented Dynamo API’s such as ProtoGeometry and RevitNodes.

Hope that helps a bit. And thanks for listening. I hope to see much more Dynamo/Python action :metal:


#8

Uh, two more things that might be helpful:

A) One of the OOTB hardcoded paths is this one:

Having a default script folder that is already in the path, is super useful when distributing Grasshopper definitions (or just normal Rhino Python scripts) that implement external modules. So something similar would be terrific in Dynamo (maybe it already is?).

B) There is also this folder:

Which has a bunch of McNeel developed modules, such as the rhinoscriptsyntax library (basically a procedural Python wrapper around RhinoCommon for people that prefer that style), and the scriptcontext module (which has some generally useful stuff, like a persistent Python dictionary that is accessible from all IronPython instances within the same Rhino session, making all sorts of neat things possible).


#9

Thanks @AndersDeleuran - We plan on looking into this more. A task has been filed in our team’s backlog.