Best Practice for Distributing Python-based plugins

Scripting
1

I’m making an updated, easier to use version of the finches shapefile import scripts. I want this version to be easy to install and use for users who have no experience with Python.

I’ve noticed that by choosing to create a script as a Command, it assigns it a folder by default. In my particular case it gave me this structure:

C:\Users\bgolder\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\
    PythonPlugins\
        Finches {1ddccafc-8c9a-4c82-bc6b-7030d655d9c5}\
            dev\
                ImportShapefile_cmd.py

I assume there are some important things to know about this folder location and structure but I can’t find much documentation on it.

I’ve been placing my external python modules in dev\ ind importing them into the _cmd.py file.

So now I have this

        Finches {1ddccafc-8c9a-4c82-bc6b-7030d655d9c5}\
            dev\
                ImportShapefile_cmd.py
                Shp.py
                ShpFeature.py
                dbfUtils.py

If I want to share this with users, so they can access the functionality in the command, what are the recommended best practices for the current version of Rhino 5?

Thanks,

Ben

PS: this is my first time using this forum. I like it! Nice work!

1 Like
2

For plug-ins created in C++ or C# one can make an RHI installer using the procedure outlined here http://wiki.mcneel.com/developer/rhinoinstallerengine/authoring

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.

3

Thanks menno,

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.

4

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 :smile:

5

Python support in RHIs is something that we want to eventually have, but I don’t believe we have full support for this yet. Sorry Ben.

6

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?

7

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?

8

Hey Ben,
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.

9

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.
10

Maybe this helps when installing

Basically, during install you set some registry keys, so that when Rhino starts it knows that a new plug-in has been installed. Hopefully that works with Python plug-ins too…

11

Ben,

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?

Bruno

12

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.

13

We just released a new script compiler. I think there is still some work involved in having python module support included. Looking into this right now.

2 Likes
14

3 posts were split to a new topic: Distributing Python Commands