Yes the new Rhino python landscape is confusing (IMO). The short version is: you should continue to use the older GhPython components whenever you want to work with the LBT SDK or LBT objects in your Rhino/Grasshopper files.
The slightly longer version is:
Rhino & Grasshopper have 3 distinct python interpreters now; a 3.x one, an IronPython one, and the older GhPython one. These three interpreters are fully separate from one another, and while it is technically possible to pass some very simple objects between interpreters, it is not recommended, and certainly complex objects like LBT rooms, models, etc cannot be easily moved between them.
The three interpreters do not share system path or dependency environments, and so installing the LBT libraries on the GhPython one will not make them available on the IronPython or v3 ones.
Unless / until the LBT components themselves are updated to work in the ‘new’ interpreters, we will just need to stick with the ‘old’ one.
There’s a lot of fixing and improvements to the new Rhino 8 script editor that Ehsan from McNeel has been working on for the past few years (and is continuing to work on). He has done a great job but, because of all the changes, the earliest that you will see us move the Ladybug Tools components over to the new Script Editor is Rhino 9.
So using the old GHPython component and old IronPython environment is currently the best way to use Ladybug Tools for now in Rhino 8. If you need to summon an old GHPYthon onto your canvas, just double-click it and search for #GHPython (with the #). That will let you bring it up instead of the new script component.
Also for this:
Ehsan gave us a method that we can call to turn the tag off in our old GHPython components. You should find that they are all gone from your Ladybug Tools components if you’ve installed the latest version of Ladybug Tools and run the LB Sync Grasshopper File component to update all of the LBT components on your canvas.
If you want to get the OLD tag to go away on your own custom components, the method Ehsan added into the Rhinocommon SDK is Component.ToggleObsolete(False). You can see that I wrapped it into a function we use in Ladybug Tools here:
So you can make use of it inside your own GHPython component in the following way:
from ladybug_rhino.grasshopper import turn_off_old_tag
turn_off_old_tag(ghenv.Component)
Lastly, I’ll add that the latest Pollination installers add the Ladybug Tools core libraries to the Python paths of the Rhino 8 Script Editor. So, if you use the latest Pollination installer, you should not have any more import errors if you try pasting code from LBT’s GHPython components into a new ScriptEditor component. This means that you can technically use the LBT core libraries in the Rhino 8 script editor if you want. Just beware that the environment of these ScriptEditor components doesn’t really talk to that of the GHPython component as Ed mentioned.
But there is a lot of power and potential in the new script editor, particularly for things like making your own Rhino commands with the LBT SDK. For example, the Rhino 8 ScriptEditor is how I made these Environmental Analysis commands that we have been shipping with the Pollination Rhino installer.
Returning to this, after a sojourn in other fields.
I have a series of scripts, that are in the original ironpython editor, and interact with LBT components. Both as pre and post processing. This therefore means that its the original iron python all the way, if I understand everything correctly.
The components refer to my own python based libraries for a series of functions, and as of now the installation needs to include that code in folder on the PC. But I would want to publish a plugin of the components.
Using IronPython, would mean not being able to use the nice new publishing features of Rhino8, if I understand correctly?
I’ve tried reading up on the old way of publishing, but do struggle a bit with the neccesary structure, yaks, and etc.
It is a good question. I for one have not really found a good ‘built-in’ way to distribute python plugins for Rhino. In case it is helpful, the process we use for the Honeybee-PH Plugin looks like the following:
We have offloaded most of the ‘work’ to dedicated libraries which we host on PyPi (Honeybee-PH, PHX, PH-Units).
For installation, we make available a .gh file which includes an ‘installer’ GH-component patterned on the old Honeybee Food4Rhino installer (pre-Pollination). This installer file allows the user to click ‘install’ in GH, and all the necessary back-end setup is done for them.
This process works fine on MacOS, but Windows is harder. Specifically: the user MUST run Rhino in ‘Admin’ mode to be able to Pip-install into the ladybug-tools python installation.
If the user is NOT in ‘Admin’ mode, python has some unfortunate behavior which will mess things up. So you need to be sure to protect against that.
This means some teams with locked down corporate systems might (will) struggle to use such an installer.
I would definitely recommend some sort of ‘versioning’ scheme be applied so you can easily keep track of which version your users have installed. This helps a lot on trouble shooting. We copied the LBT automatic version numbering setup which is run by GitHub Actions - I highly recommend something along those lines.
hope that helps - and if you find a better ‘built in’ method for distribution I’d love to know it!
