Automatic package updates broken in Rhino 8 SR 7

Rhino Developer Yak
1

I discovered a strange bug in Rhino’s package manager that seems to have been introduced in Rhino 8 SR 7. How to reproduce:

  • Install ShapeDiver version 1.17.1-beta.1
  • Restart Rhino
  • On loading one of the plug-ins contained in the package (e.g. running the ShapeDiver command, or when starting Grasshopper), the package folder %USERPROFILE%\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\ShapeDiver\1.17.1-beta.1 gets copied to %USERPROFILE%\AppData\Roaming\McNeel\Rhinoceros\packages\8.0\ShapeDiver\1.17.1, i.e., the semantic versioning part of the version gets stripped of.

The 1.17.1-beta.1 folder stays there, which means next time when starting Grasshopper there are conflicts popping up.

I discovered this when testing multi-targeted packages: .NET multi targeting for yak packages - #2 by curtisw

First I thought it’s an issue related to the multi-targeting feature, but it also happens for normal packages like the version 1.17.1-beta.1 mentioned above.

The problem happens regardless of using .NET Framework or .NET 7.

This means semantic versioning is unusable currently, which I consider a big problem. Can this be reviewed asap please?

2

Hmm, this happens regardless of semantic versioning. If I install version 1.16.1, then restart Rhino, version 1.17.1 gets installed and the 1.16.1 folder stays there (i.e., “File conflict” popups showing up when loading Grasshopper).

Seems like the package manager is automatically updating to the latest version (but leaving old versions behind)?

3

Aha, found the advanced option Rhino.Options.PackageManager.CheckForUpdates. Seems to default to True. When setting it to False, the problem does not happen.

Anyway, this is a serious problem, because the old versions do not get removed.

4

Also the following is strange UX:

  • User selects a specific plugin version and installs it
  • After restarting Rhino the latest version gets installed without the user being made of aware of it.

In case this automatic update behavior is intended, the user shouldn’t even be able to select earlier versions of a plugin in the package manager.

6

Thanks for reporting this @snabela. Definitely an unintended consequence of adding auto-update in Rhino 8. Looking to improve this ASAP to make it easier to install older versions, or stick with a specific version.

1 Like
7

A hint on how to switch off automatic package updates until this has been fixed:

image
image1824×1492 165 KB

1 Like
8

RH-82045 is fixed in Rhino 8 Service Release 8 Release Candidate

9

RH-82045 is fixed in Rhino 8 Service Release 8

10

As of Rhino 8.8 you can run the PackageManager command and find a new checkbox to toggle the automatic check for updates on start. No need to go fishing in the advanced settings anymore!

image
image1674×200 36.3 KB

1 Like
11

Continuing the discussion from Automatic package updates broken in Rhino 8 SR 7:

@brian @Dan I have been tracking this issue for a while, and it seems it still does not work reliably. I have upgraded to the latest build, but Rhino keeps updating Lunchbox even when I turn off automatic updates in the package manager. Also, in the advanced options, the check for updates is set to false. I am now trying a workaround where I can delete the address for the updated sources. It’s not ideal, but let’s see if that makes the trick.

image
image751×282 14.1 KB

image
image897×198 10.4 KB

image

I need to keep Lunchbox in version 2023.2.2.0, as this is the latest version that works with Rhino Inside Revit. The two 2024 releases don’t load in Rhino Inside Revit, making many of my definitions unusable.

I would appreciate any advice or updates on this.
Thanks