Convert ghpython script to grasshopper component

Lets say I have a script I’ve written in python and now I want to share it with people, but I don’t want them to see or change the code, how do I turn my script into a grasshopper component? There are plenty of add-ons for grasshopper where you download file and drop it into the grasshopper components folder. How do I export my script to a form that can be loaded automatically in that way. Currently I have to copy and paste python scripts from a save grasshopper file containing all my scripts.

Hi lawrenceyy,

You can make user objects. See
http://api.ning.com/files/VVtlaRM5YoVtghh58d2iXeGuJSy0kwacYTq75oPXo3RyhOcrJeyxlQmTicotiEtnTJ7KpEIZzgP80NgOK8EHbu*8oAHY/CreatingCustomComponents.pdf
It’s from a previous grasshopper version but I think it’s still useable.

1 Like

Just an addition to siemen’s reply:
Once you create a cluster (with your ghpython component inside it), right click on it, and choose “Assign password”.

Although, as a member who contributed vastly from the help of the community and from being able to look at other people’s code, personally I am a big supporter of open-source.

cluster_password.gh (11.2 KB)

1 Like

To add to Siemen and Djordje’s replies, I wanted to note that with Rhino WIP, you can compile Python scripts [(see Giulio’s comment here)] (http://www.grasshopper3d.com/forum/topics/creating-a-custom-gh-component-in-python?commentId=2985220%3AComment%3A1267859). We’re all hoping this feature will be developed and implemented in Rhino 6 / GH2.
/SPM

You can also compile the relevant ironpython classes/function to a .dll and call that assembly from your GHPython component. That said, it’s pretty damn easy to decompile a dll. So the whole thing might be a bit futile. Also, what djordje and Stephen said :slight_smile:

1 Like

Hi Lawrenceyy

There are a number of ways to achieve what you are asking:

  • If your goal is simply not to allow editing and modification, then the simplest method is to create a Cluster, and put the cluster in a UserObject. The source code is still written in plain in the .ghx file, but it will not be easy to extract it from within Grasshopper.

  • If you want to actually create a lower-level type of code from your higher-level Python (“compiling”), then this is supported in IronPython by the clr.CompileModules() function. The assemblies that this creates are not usual .Net assemblies, but can be loaded by the same IronPython runtime that created them.
    You can manually create a mechnism in a Python component that would load such an assembly, but this is usually a bit cumbersome.

  • In the new GhPython for Rhino WIP, we support automatic loading of such assemblies. They have to be structured in a object-oriented way, have a .ghpy extension and be placed in a watched directory.

(when I started typing this, I noticed a bug in .ghpy component compilation in Rhino WIP. I fixed it, and then the rest of the people answered your question nicely. This feature will be fixed in next week’s WIP).

Thanks

Giulio

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

1 Like

I think the first solution (cluster and turn to UserObject) will work just fine. I am curious about compiling .dll though. Is .dll just a file where we save all our def() and class() so those bits of code don’t need to appear or be written into our ghpython scripts? Transparency and password protection aside, are .dll just textfiles? I’ve seen a similar situation- I bought an Adafruit servo driver board for my raspberry pi and to control the board I needed to reference Adafruit’s libraries. I don’t remember if it was a .dll, but I remember opening the library and it looked like a textfile with a bunch of functions and classes.

And what is the deal with all these different versions of python? What are the noticeable differences? I’ve only noticed little difference between ghpython and python 3 that I use for my raspberry pi (for python 3, integer division seems to be the default and you have to put parenthesis around things you are printing).

IronPython assemblies are not that easy to decompile AFAIK. They rely on their reference runtime.

They are binary files.

That would be a great question for a new thread. There has been some discussion about this on the GH forum. Right now, the whole Rhino uses 2.7. Like many (most?) enterprises.

Ah yeah, that makes sense. In that case perhaps that would be an approach if one is keen to “protect” the source.