I am building a plugin for my team (first, and maybe for share it later) using the new Rhino 8 ScriptEditor. I have two major blockers regarding the distribution of my toolset via RHP/YAK.
1. Dependency Management for Licensing
My project includes 20+ command scripts and one core module: MM_InitSecurity.py. This module handles license verification.
I need this security script to be centralized. However, when I publish the project, the scripts fail to import this module on other machines.
What is the “official” way to include a shared licensing module so that all scripts in the RHP can access it without manual sys.path manipulation by the end-user?
2. Custom Toolbars and UI Organization
Currently, when I publish the plugin, Rhino generates a default toolbar where all commands are listed in alphabetical order.
This is not practical for a professional workflow. I cannot create tabs, group buttons, or define a logical order for my tools.
I’ve had a lot of trouble including a custom .rui file in the package. It seems the published package doesn’t always load the custom UI correctly, reverting to the basic alphabetical list and most of the time, when I save my toolbar, it’s seems not working and I don’t find if I can export it instead.
So, how can I embed a fully customized toolbar (with tabs and specific button orders) within the .rhp or .yak so that it installs and displays correctly on the client’s machine?
I want to avoid a “zero-security” approach where I have to paste the license code into every single script. I’m looking for a clean, professional way to distribute a secured and well-organized plugin.
Any help or “best practice” workflow would be greatly appreciated
Python libraries/modules added to the Bibliothèques/ section of a project are embedded in the compiled assembly and deployed on the target machine under %APPDATA%\McNeel\Rhinoceros\packages\8.0\<your-package>\<version>\libs folder. This path is then automatically added to the module search paths for the scripts.
Let’s troubleshoot this. Would you mind running a command from your plugin on a user machine and then checking this folder to make sure the library is correctly deployed?
I am improving this for Rhino WIP, but for Rhino 8, the current workaround is to create your own .rui file and replace the one in the .yak package generated by Script Editor. The .yak file is basically a zip file that you can unpack, change and repack. You can also use the yak command line to repack the .yak file.
Thank you so much for your reply and the helpful explanation. I wanted to give you a quick update on our progress.
First, your workaround for the .rui file works perfectly! We unpack the .yak, inject our custom .rui file, repack it, and the toolbars load exactly as expected on the target machines.
Regarding the Python modules in the libs folder, we managed to get it working. We implemented a dynamic scan in our scripts to locate the specific %APPDATA%...\libs generated path on the user’s machine, and it successfully imports our module now.
However, we encountered a tricky bug with the Script Editor compiler that you might want to look into: When we include binary files like .png images (used for our Eto UI) in the project before publishing, the .yak compilation process seems to corrupt them. Once deployed on the target machine, the images are structurally unreadable by Windows. Trying to load them via Eto.Drawing.Bitmap throws a COMException (0x88982F50): No imaging component suitable to complete this operation was found.
Our current workaround is to exclude the images from the Script Editor publish process entirely, and instead manually inject the pristine .png files directly into the .yak (zip) archive at the same time we inject the .rui file. This preserves the binary files and works flawlessly.
Thanks again for your support and the continuous improvements on Rhino 8 (and 9) !
Give me a bit more detail about including the .png files. Are you adding them to the Shared/ section of the project panel, or are they included manually in .yak package?
I will run a test here locally and will report back.
I tested a simple project with two .png files added under Shared/ and built and installed the yak package for this project on macOS and Windows. Both seem to include the same .png files in the installed yak package folder.
If you can give me a few steps to replicate the error I can me a ticket and get it fixed.
Thanks for looking into this and running the test! Your finding actually points exactly to where the issue happened. You tested by adding the .png files to the Shared/ section, which works perfectly. However, on our end, we had included the images inside a subfolder alongside our Python modules, and added that entire parent folder to the Libraries/ section of the project panel during the Publish process (sorry for that, I’m a newbie :))
It seems that when binary files (like .png) are placed in the Libraries/ section instead of the Shared/ section, the compiler tries to process or encode them as text/code, which irreversibly corrupts the binary structure of the images.
Here are the exact steps to replicate the error:
Create a new Python project in the Script Editor.
In the Project Panel, add a folder containing a standard .png image to the Libraries/ section (NOT the Shared/ section).
Publish the project to create the .yak package.
Rename the .yak to .zip, extract it, and inspect the .png file inside the deployed libs folder (or install it and check the %APPDATA% path).
The resulting .png file will still be there, but it will be corrupted and unreadable by Windows/image viewers.
Now that we know the Shared/ section is the proper place for UI assets, we will use that moving forward! However, it might be helpful if the compiler could either safely copy binary files found in the Libraries/ section or throw a warning, so other developers don’t accidentally corrupt their assets.
Thanks again for your time and guidance, it’s hugely appreciated!
I wanted to give you a quick update on our progress.