Tutorial: creating a Grasshopper component with the Python GHPY compiler

Hi @sgaray

if you are doing this from an event handler, then it should be fine. Never do this within a solution.

Just keep in mind that you’ll need to use standard Grasshopper input parameters, not Hint-based scripting parameters. Compile a sample component with the Hints that you need, then choose to copy the code. It will show exactly what types are expected.


Giulio Piacentino
for Robert McNeel & Associates

I was doing it from the solution itself, will follow your suggestion.Thanks!

A post was split to a new topic: Problems creating GHPY files

2 posts were split to a new topic: Documentation strings not used in GH_Component SDK mode

A post was split to a new topic: clr.AddReference() for compile GHPYs


Can the other sections of the compiling window be defined from inside the code?



They cannot, sorry.

If you compile often or more than a single component, you must compile all components on your own using clr.CompileModules(). Do not ship dozens of components in single GHPYs, because the loading time for each single GHPY is quite long (it does not take almost any longer to load 1 to 10 components in the same file).

1 Like

I like this battery. How is this battery code written??

Sorry, I’m not sure what you mean from your post.
But if you are wondering about the name tag above the component, that probably comes from the Bifocals plugin.

@piac, I was wondering if you could clarify this please? Is setting node properties like this fine in the initial lines of a uncompiled GhPyton node?

Hi Anton,

nice blog!

I think I need to see a sample of your code to understand what you ask. General, registering inputs and outputs should be done from the methods that are meant for that:


This will ensure that the methods get called only when Grasshopper needs them. When you copy the compilable code, the boilerplate generator creates these methods for you, using similar inputs as the ‘Hints’ options you chose for the scripting components. Because of the intricacies of the Grasshopper SDK, a Hint is not a Param by itself, so there is a translation.

You can also change the network topology or the solution properties (tree, list, ecc) from other methods. This may or may not have unintended consequences. Especially bad is if you change them while the solution runs. If you do this, you might be getting two results: if you do that from the SolveInstance method, you might stack overflow, as solving will call your method that will call solve that will call your method…

The other option, if you change these from another thread, is that you may not see any results or the solver may crash. So, in few words: do not change the network topology, solution properties (locked, etc) or options (list, tree access, longest list, etc) while the solution runs.

Thank you!! (Need to update it more often though :sweat_smile:)

I replied to this thread mostly because it’s one of the few places I found ghenv.Component.Params.Input[n].NickName etc mentioned. It is a bit off topic, and for that I’m sorry. I have compiled PY scripts before and this guide was a great resource for learning that :).

I’m mostly wondering about settings NickName and Name, see sample below, nothing more. I know I can set descriptions with docstrings, but it’d be neat to set Name and NickName in the script.

Is this safe usage?

from itertools import groupby

ghenv.Component.Params.Input[1].NickName = "gcode"
ghenv.Component.Params.Input[1].Name = "GCode to be processed."

ghenv.Component.Params.Output[1].NickName = "out_gcode"
ghenv.Component.Params.Output[1].Name = "Processed gcode"

out_gcode = []

# remove duplicate lines
for (key,_) in groupby(gcode):


For inputs and outputs, the right way is to use docstrings:

1 Like

Thanks for your reply.

I understand that I can set the mouse over hints using docstrings, but can I use it to set names of the inputs without having to right-click the component? I’m also curious about if it’s possible to change title of component, the message and typehints. If not that would be a great addition to future GhPython releases.

Also, x in example below refers to NickName, right?

"""Provides a scripting component.
        x: The x script variable
        y: The y script variable
        a: The a output variable

You should not do that, as the docstrings is the correct way to do that. And you especially should not do that during a solution (from within the RunScript method). GhPython might not work correctly.

You can change the name and the title of the scripting component by right-clicking on the component, and changing the NickName. GhPython does not use that value, so you are safe regarding that, but if other components do, then you are not certain that the order of execution will stay as it is forever. Sorry, but I need to warn you.



Giulio Piacentino
for Robert McNeel & Associates

Ok, thanks!

2 posts were split to a new topic: Change of behavior after GHPY compilation

A post was split to a new topic: Docstrings after SDK compilation mode

A post was split to a new topic: Ghenv ghpy compilation