Bug? Package Manager Happily Installs Mac Package on Windows

I have a yak package which I believe is marked correctly for Mac:
xray-1.0.2-mac.yak

A drag and drop install into Rhino 8 for Windows attempts to install.

Expected behavior: A warning that it’s a Mac package.

Is this working as designed?

In this case it does work ok in 8.0 (it’s the core 7.0 version of the plugin- I’m shipping 4.8 as the windows version to avoid questions from people who have set Rhino 8 to use that).

In Rhino 7, it tries to install but fails. The problem there is that it pops up the plugin can’t load window and says to contact the vendor but all of the contact information is blank so the user is kind of stuck.

(yak actually named it xray-1.0.2-any-mac.yak, with that name it behaves the same)

It came out of Yak with no version information (unlike the --platform win version, which gets named after 7.32)

If you want to see if the plugin is working after install, the only command is xray. For me it’s functioning normally.

Side note which may or may not be related but which I should mention: I get a warning from yak building the package

Inspecting content: XRay.rhp
WARNING: Failed to inspect file and update manifest: XRay.rhp

Creating xray-1.0.2-any-mac.yak

xray-1.0.2-mac.yak (214.3 KB)

@Nathan_Bossett did you have any luck removing the warning Failed to inspect file and update manifest: ?
I would also vote that platform should be used to filter the package list.

Would also be helpful to be able to specify the Rhino version via a CLI flag - particularly when the inspection fails.

EDIT: the rest of this answer looks at build, not spec (create manifest). the spec step to create a new manifest file also runs for me without a warning.

That was November- my packaging has evolved a bit since then and I don’t see the warning any more whether creating Windows or Mac packages. Other than creating the package, I haven’t been doing anything with Mac because of lack of access to machines to test on where I was.

I’m not sure if the problem going away is the result of changes at my end or if something changed with Yak at the Rhino end, but I’m happy to share what’s working for me.

The plugin is a single rhp file.

My (working) manifest is:

---
name: Xray
version: 1.0.5
authors:
- Falcata Group
description: >-
  Detailed Geometric information about selected objects:
        Dimensions, volume/surface area/length, degree of curves/surfaces,
        and more plus easy copy/paste of those values into other tools such as
        MS Excel.  Load it up, run command xray to open a window, and click on Rhino Objects!
        Free trial, 15 days - FLCT-XP00-0000-0000-0000-0000.
        Windows only (for now - want to be a Mac Alpha Tester?).
url: https://falcatagroup.com

The packaging batch file follows. For context, the batch file exists in a directory above the version directories. I don’t put it in the directory with the data it acts on so that YAK doesn’t see it when creating the manifest.

I comment out lines depending on what I want: a manifest rebuild or specific package versions.

REM update directory as versions released
cd .\1.0.5\
REM "C:\Program Files\Rhino 8 WIP\System\Yak.exe" spec
"C:\Program Files\Rhino 8\System\Yak.exe" build
"C:\Program Files\Rhino 8\System\Yak.exe" build --platform win
"C:\Program Files\Rhino 8\System\Yak.exe" build --platform mac
REM platform can be ein, mac, any
REM "C:\Program Files\Rhino 8\System\Yak.exe" push
cd ..

I have the manifest building step commented out here because mine works. Mine is basically autogenerated plus editingthe comments type fields.

The result if none of the packaging lines is commented out is:

01/05/2024  11:09 AM    <DIR>          .
01/05/2024  11:08 AM    <DIR>          ..
11/26/2023  02:47 AM               545 manifest.yml
01/05/2024  11:09 AM           223,416 xray-1.0.5-rh7_32-any.yak
01/05/2024  11:09 AM           223,425 xray-1.0.5-rh7_32-mac.yak
01/05/2024  11:09 AM           223,425 xray-1.0.5-rh7_32-win.yak
11/26/2023  03:44 AM           332,680 Xray.rhp

I think I was just renaming the files to get the one for 8.0 (for a while there was a breaking difference between 7 and 8 but no more).

1 Like

Thank you @Nathan_Bossett I really appreciate the detailed write up an example.
I envy your simplicity, at last count our plugin totals over 80 dll’s.

would anyone be able to confirm whether it is sufficient to simply rename the yak file in order to restrict a package to Rhino 8? i can at least do that even if the inspection of my dll by yak fails

I can confirm that the rename worked for me in getting separate distribution downloads for 7 and 8 on food4rhino.
Xray | Food4Rhino

Also, Steve B said that a YAK package is only a renamed zip file (as of June 2023, thread link below). I just tested that statement again by renaming one back (YAK->ZIP) and opening it in windows explorer, so it looks like there’s no hidden data inside which Rhino looks at, only the manifest file and whatever other files you include.
Help using Package Manager to distribute a plug-in built with C# - Rhino Developer - McNeel Forum

I haven’t tested Rhino version number checking on actual installs to confirm that Rhino blocks the attempt if the version isn’t right, but I started this thread because it apparently wasn’t checking Win/Mac to see whether it should try to install.

Wow, now that’s a bit of automation and testing.