I haven’t tried this with Python plug-ins, but the following text on the page suggests that it should work for Python plug-ins too:
Because the Rhino Plug-in Installer Engine unzips your .rhi file into
a directory specific to your plug-in, you can include anything you
want: help files, documentation, etc. But you can only install things
inside your own plug-in directory. So long as your .rhi file contains
sub folders, everything will install correctly.
@stevebaer should be able to to confirm this I hope.
This makes me wonder if I can simply zip the directory and change the extension to .rhi
If the installer can unpack other files besides compiled plugins, then it seems like it should be able to unzip uncompiled python modules. I just don’t know if the installer would require a compiled plugin.
Zipping a directory and renaming is exactly what I do, except that I use a c# plug-in. Looking at the paths in your initial post, these are different. It may be that the installer, which does version checking prior to installing and changes the registry after installing, does not (yet) recognize the Python directory lay-out. The only was is to test this with the directory you now have
Thanks for letting me know Steve. In that case, I’m wondering about workarounds. Perhaps I can make my own minimal installer of some sort, or ask people to put files in a particular location.
The GUID generated for the plugin - is that key meant to be unique for one version of the plugin, one copy, or for all versions of the same plugin? How should I treat the importance and consistency of the key?
Also, is there an easy way for users to access the python plugins folder? It seems like an obscure folder to navigate to, and AppData is often a hidden folder.
I guess the more important question is: If .rhi doesn’t work, what is the next best thing? How should I distribute a plugin or script?
I’m not at all tied to making a .rhi from my python script. I’m just trying to figure out the best way to share the script with users who have no python experience.
Maybe for now I should just package the plugin with a script that copies everything to the appropriate folder. If I do that, should I ensure that the copied package retains the GUID that was created when I made the plugin? Would copying everything to the correct folder be sufficient to “install” the plugin?
The process right now is really lame and we definitely need to come up with an easy approach. I would like to tune up the rhi system for this, but for now. Probably the best would be to copy the files to the correct location on the user’s computer.
I would keep the same Guid since that can be used to uniquely identify your scripts.
Steve, I tried a test install on another user’s computer. I noticed a couple major problems:
the PythonPlugins directory does not exist by default. It must be created.
The plugin is not loaded until a user opens the python command script at least once in the Rhino Python editor. This means that if you copy the files and directories into the appropriate location, and restart Rhino, the command is not available, and a user must first open the python script (as if they were going to edit it) before the command will be available in Rhino.
Have you tried using the python compiler (see link below)? Should work if your python script(s) don’t depend of other python files you’ve created (i.e., does not depend on calls like “from mymodule import *”). I’m anxiously waiting for the release where the compiler has multi-file support. Steve, any idea when multi-file python compilation will be supported?
The most recent changes to the GhPython component make it easier to distribute the script as a Grasshopper component than as a command (though I think it would be make more sense if it were a Rhino command). So I’ll just keep it in Grasshopper for the moment, until I can distribute an installable package of some sort.