I have installed ladybug-core library, but when I try to use the ladybug library in the Rhino 8 Script Editor (or a Rhino 8 Python component), I am getting an error “no module named ‘ladybug’”, What am I doing wrong?
Hi @Gowtham ,
I changed some things about your question since you originally said that you were using GHPython but it’s clear from your screenshot that you are NOT using GHPython.
GHPython is the Grasshopper Python editor that was used through Rhino 7 and can still be accessed in Rhino 8 by double-clicking the Grasshopper canvas and typing #GhPython Script:
If you have Ladybug Tools installed and you type from ladybug.epw import EPW in an actual GHPython component, it will work out of the box no matter what your version of Rhino is. However, it will not work out of the box in the Rhino 8 “Python 3 Script” or the “IronPython 2 Script” components:
The new “Python 3 Script” and “IronPython Script” components that @eirannejad added to Rhino 8 use completely separate Python environments from GhPython. So, if you want to use Ladybug Tools SDK in those other environments, you have to make sure that the dependency paths of those other environments know where Ladybug Tools SDK is installed on your system. Luckily @eirannejad added a very elegant way to do this, which just involves adding comments at the top of your script to specify the script’s dependencies.
There are many different ways that you can use comments to specify the script’s dependencies, which @eirannejad outlines here on the McNeel foum. But my preference is to do it with the following line of code, which works if you have installed Ladybug Tools SDK via the Pollination single-click installer in it’s default location:
# env: C:\Program Files\ladybug_tools\python\Lib\site-packages
So just add that to the top of your “Python 3 Script” and “IronPython Script” components and everything will work:
I hope that helps.
2 Likes
@gotham You can add the ladybug search path to the Python search paths in the options window:
https://developer.rhino3d.com/guides/scripting/editor-configs/#editor-paths
@chris The Ladybug installer can drop a file in ~/.rhinocode or any of the directories listed in the page below to automatically add search paths to either python 3, 2, or both:
https://developer.rhino3d.com/guides/scripting/advanced-pthfiles/#path-files
1 Like
Thanks, @eirannejad .
That’s really good to know that there’s a way to add our installation folder to the Python path without needing to add the comment at the top of each script. Granted, I think this comment system that you set up is really nice and I still recommend that people use it. It makes the dependencies of the script explicit and, as the Zen of Python goes, “explicit is better than implicit.”
But we can consider having our installers add the LBT installation folder to the search paths per your suggestion.
I can test this myself but, if the ~/.rhinocode folder has not yet been initialized for a given user but we try to create the folder during our installation process with just the .pth file in it, will this .pth file be used when the rhinocode folder eventually gets initialized? If so, that gives us a reliable way to easily add it to the Python paths for everyone and maybe we can say that people don’t have to put the dependency comment at the top of their scripts if they don’t want to. Otherwise, this method might not be the most reliable and I’m still going to recommend that everyone use the comment system.
Yes and the .rhinocode folder is one of the many options for where the .pth files can be located.
Thank you so much !!! I did not know about Gh PythonScript
Thanks @eirannejad ,
I see that, even if the Python environment has not been initialized in Rhino 8, I can still write the .pth files into an otherwise empty .rhinocode folder. They’ll be ignored the first time that the Python environment is initialized but, after restarting Rhino, I can import Ladybug Tools without needing the comment.
Given all of this, I’ll make a tweak to our installers so that we write these .pth files in to the .rhinocode folder or we create the folder if it does not yet exist. This way, people have access to the Ladybug Tools SDK in these other environments if they want.
1 Like
FYI, @eirannejad ,
I just added a method that will run as part of our single-click installer, which will write (or append to) the .pth files in the .rhinocode folder:
This way, people using the Rhino 8 ScriptEditor or Rhino 8 Python components will be able to import all of the Ladybug tools core libraries from their installation without needing to add any header comments to their scripts.
And, even though all of the Ladybug Tools components are still GHPython and will be for a while until our community is predominantly using Rhino 8 (or 9 in the future), making this change now will hopefully set up some good practices of just using the one (latest) version of the LBT core libraries that come with our installation. For example, this should help prevent dependency conflicts down the line of people having one version of the LBT core libraries living in the .rhinocode folder (pip installed via some comment in a script) and another “official” version of the LBT core libraries living with their Ladybug Tools installation.
@eirannejad ,
Am I correct that search paths specified in these python-2.pth and python-3.pth files will take precedence over duplicate copies of packages found in:
C:\Users\[USERNAME]\.rhinocode\py39-rh8\Lib\site-packages
or
C:\Users\[USERNAME]\.rhinocode\py27-rh8\Lib\site-packages
If so, that is great and I’m sure that this will save users of the ScriptEditor many headaches of having an old copy of the core libraries loaded and not knowing why they are missing a certain Ladybug Tools feature.
Short answer is No. The site-packages folder is added by python engine during initialization and is one of the first folders on the search path stack.
.pth overrides show up after default python paths but before any environment created by RhinoCode for the script.
Let me know if you have any ideas on how we can improve.
Thanks, @eirannejad .
I did a test just to confirm and you are right:
I guess this is alright. Is there any way to uninstall the packages in the .rhinocode folder if I wanted to make sure that someone was using the official version of our core libraries that come with our installer rather than some version they pulled down at some point through a comment in the component?
Is deleting the .rhiocode folder the only way to be sure that they have uninstalled all Ladybug Tools core libraries?
Not at the moment. Preferably this should be in ladybugs documentations to let users know they need to clean their python 3 environment and search paths. Ideally ladybug packages would be on Pypi and installed by the editor when needed.
Deleting the .rhinocode folder is not a good idea. It contains editor configs and other user-specific files that should not be deleted.
Thanks, @eirannejad .
I appreciate the suggestion and I understand that it can work for some projects. But we have learned the hard way that just writing documentation that says “clean the Python 3 environment before installing Ladybug Tools” is not going to prevent this forum from getting dozens of posts entitled “Ladybug installation does not work.” Maybe manual cleaning instructions like that could have been manageable back when Ladybug Tools only had 5,000 downloads but it’s not something that works well now that the scale of the community is around 750,000 downloads.
If you could give us an automated way to clean out the .rhinocode folder that we could run every time someone uses a Ladybug Tools component, then we could probably rely on that. Is there a certain way to do this that you would recommend?
If not, I think the simplest way to help us use the new Python components instead of the old GHPython is just to give is some way (really any way) to override the version of Ladybug Tools that users may have installed for themselves in the rhinocode folder with the version that we know is compatible with the users’ installed Ladybug Tools components. That would definitely address our biggest road block to using the new Python components.
Also, in case it was not clear all of our Ladybug Tools packages are on PyPI as you see here:
But you can also probably see that we push changes to those packages almost every day. So it’s very easy for the user’s installed version of Ladybug Tools Python packages to get out of sync with their Python components if we don’t have some way to keep the two synced.
I know that Ladybug Tools is not your typical ScriptEditor user and the problems we face are different from those that you originally designed the script editor for. So I fully understand if you don’t prioritize our issues and I know that you don’t want to let the edge case drive the main use cases. But I’m just letting you know the challenges we face in case you find there’s a way to help us at some point.