The basic steps are to add the path of the dir the Python module or package to be imported is in, to sys.path
if it’s not already in there. If the project will only be run on your machine, any path you like can be hard coded as a string literal. In the RhinoPython settings, the user can add a path to sys.path too, essentially acting like setting PYTHONPATH. That would then be part of your installation instructions.
But if the code’s shipped via Yak or food4Rhino, it’s necessary to ask Rhino or Grasshopper where are the folders, either of the plugin or the Grasshopper dirs, that the user must then install your plug-in into (whether they know that if using food4Rhino, or if Yak does it for them in which case the user doesn’t need to know where it is, in order for your plug-in to its own files. It can use Rhino’s help instead).
This was useful, but much more boilerplate was necessary too - a lot of extra stuff needs to go into your project dir to ship with yak - and then version bumping and all the uninstall and install steps are needed to test a release properly. It felt like I might as well write it in C# instead. Testing a dev version using a hard coded path to the repo is easier. E.g. if you first del sys.modules[your_module_or_package]
and importlib.reload(your_module_or_package)
restarting Rhino can be avoided. But this does not test the same import steps your users will have to do:
path = os.path.dirname(Rhino.PlugIns.PlugIn.PathFromName("YOUR_PLUGIN_NAME"))
if path not in sys.path:
sys.path.append(path)
import your_module_or_package
Rhino Script Compiler and building Python-based plugin on macOS? - #9 by stevebaer?
I recommend Grasshopper instead. It’s possible to write Python code using nearly all the modern tooling. If using CPython3 components, it’s also possible to ship via PyPi, and avoid Yak entirely.