Graceful upgrade to the Package Manager

Rhino Developer Yak
1

Hi @will
We’re deciding which update technique to use for our plugin, and are trying to work out if it’s possible gracefully upgrade from an installed plugin (via rhi/macrhi) to a package manager version. For this, we have two goals:

Checking for Updates (resolved)

Our current tooling involves:

  1. CI to build and publish .rhi/macrhi to our server - with bundled .rhp and .gha
  2. Auto updater in plugin which checks our server for updates and alerts the user if any are available, with a one click to download and install.

The ideal scenario would be:

  1. CI to build and publish to yak
  2. Check the PackageManager in-plugin to determine if updates are available,
  3. Launch the package manager to the correct update view if an update is available (or even better, provide a button which performs the equivalent of pressing “Install” on the GUI")

For each step:

  1. CI publishing is straightforward - thanks - Yak on a CI server - #6 by camnewnham
  2. In theory I could call the CLI and pipe the string output from yak search - is there a better way? Also looking for it to be cross platform with Mac.
  3. This is almost possible / close enough with -_PackageManager -Search

Worst case for (2) - we still store the version number for the latest version (as part of CI), the plugin makes a call there to check if it is up to date, and if not it opens the package manager (3).

However since this means we still need to retain an API endpoint for checking for updates there’s somewhat less incentive to use the package manager in a hybrid system

Gracefully overwriting existing installs

Part 2 - From brief testing, the package manager doesn’t seem to play nice with existing plugins installed via .rhi. Ideally the package manager would replace / uninstall the existing version.

For testing, I followed these steps with a sample plugin:

  1. Install colorpicker6.rhi from food4rhino
  2. Verify plugin is installed/working with the ColorPicker command
  3. Restart Rhino
  4. Install ColorPicker via the package manager
  5. Observe error: Unable to load ColorPicker.rhp plug-in: ID already in use.
  6. Restart Rhino
  7. Observe error: Error loading - ColorPicker. Note that a version of the ColorPicker is installed but since Rhino is trying to load both this error happens on every launch.

What we’d like to do is prompt everyone to update without bricking existing installs, following the process:

  1. We use our existing update method to ship a new version that has the capability for checking for future updates via the package manager
  2. When we publish another update, the user is prompted to update with the package manager
  3. The user updates via Yak and and all future updates are managed in this way :slight_smile:

Is this feasible?

1 Like
2

Anyone?

I see notices for the depreciation of the rhi format but no graceful upgrade path:

image
image874×187 16.2 KB

3

I don’t have a plugin in this situation, but a few points:

I don’t understand the purpose of step 1.

Why not ship this update at a point when you know that you’re ready to switch to Package Manager and the update is sitting there waiting? Why do you need to build in the ability to look for exactly which version number update is available in Package Manager or hit a server at all to know this?

I would suggest breaking ID numbers (not sure what Mac uses?) so that the plugin looks like a new plugin to Rhino: it installs cleanly and doesn’t have any filename/path collisions.

Build the ability to remove the old version into the new version. That part might include some unloading of the existing one if Rhino supports it and if Mac views the file as free to delete at that point or some other mechanism like a little separate executable that the plugin starts while Rhino is running and waits until it closes, or that the user is instructed to run while Rhino isn’t running- whatever’s convenient.

4

Hey @camnewnham,

Part 1

Updates

  1. You can definitely use your CI to Build and Publish a Yak Package. As you’ve found.

  2. For updates, I see a few options
    2.1 - You can more simply do a local check with yak.exe or for Mac there is a script mentioned in this page, but Rhino 8 only Rhino - What is the Package Manager?
    2.2 - To keep things universal you could the Yak Endpoints instead to get a more cross platform version which would return some nice JSON e.g → https://yak.rhino3d.com/packages/ColorPicker

  3. You can open the PackageManager to a specific plugin page by calling

RhinoApp.RunScript("-PackageManager Search MyPluginName", false);

Part 2

You’re spot on here I can’t help with this bit and it’s a bit of a pain for us too.

– cs

5

Yes - that is the intention for the first version.
The reason for including a version check within the plugin is to be able to notify people when an update is available as this is for a web-connected service. Though @csykes has pointed out that this is easy enough - thanks!

I think that is good enough for the first part Checking for Updates

Good idea - I hadn’t considered that. The plugin in question also bundles a grasshopper plugin, so changing Ids could be painful (though perhaps only changing the Rhino plugin Id would be necessary).

And this is still somewhat problematic if the new version won’t load because the old one is still installed :confused:

I’m hoping there’s a simpler solution…

6

For posterity, the route I went down was:

  1. Keep the legacy infrastructure in place. Existing users continue to use existing update mechanism.
  2. Put new users on the Yak “track”. Update prompts launch the Package Manager.

Eventually (Rhino 9 :rofl:) legacy infrastructure will be deprecated, until then I will need to maintain both.

C# wrappers for the yak version/package queries are here