Thanks, this helps me a lot in understanding your process. I have added the ability to set version numbers to the compiler so you may be able to use that to help make decision. I’ll need to think about how to make this easy to access from a script.
I’m focusing on V6 and V7 as targets with this version of the script compiler. I can tweak things so you can still create a V5 plug-in, but at the moment the plug-ins created with the new compiler are only for V6+. I have also removed the rhi compile option in favor of always just generating an rhp and a yak distribution. I can add the rhi logic back if we find a strong need. For now you can manually create rhi files if that is your preferred method of distributing your plug-ins. @will has been thinking about ways to make it easy to host your own private yak server for maintaining internal yak packages which are a much better solution for keeping everyone up to date with the correct version. By yak, I mean the TestPackageManager
command in V6 and the PackageManager
command in V7.
This new compiler targets V6, so V5 won’t be able to load these plug-ins. Is that a problem that I need to work on?
I can totally understand. The current situation doesn’t really help people maintain good coding habits by having reusable functions. I think I can get this to work by unpacking modules to a temp directory, adding this temp directory to the top of the search paths and then running the script.
No, the script compiler is an independent exe that includes an embedded V6 RhinoCommon that plug-ins are compiled against. We can include this in V6 as well or ship this as an independent exe.
Getting this in the WIP is more of a convenience for me so I can keep updating the project and let everyone stay in sync.