Hi Guys,
I’ve just uploaded my first set of Grasshopper Components to the Package Manager.
This is also my first Plugin compiled using the new Rhino 8 script editor.
I made a demo GH file with the components, then un-installed the plugin to see the experience of a user being sent a script with them installed.
This is what came up:
The Plugin is called DKUI but the package manager is looking for DKUI.Components. How do I get these names to match/the plug in to automatically load?
Cheers
DK
OK, I’ve tried added a Python command “hello world” to the project to see if that fixes the naming issue. Still no dice - if you dont have the plugin installed when you open a GH file the Package Restore still goes looking for the DKUI.Components name.
HELP PLEASE!
The GH Python to Script Editor to YAK to Package Manger workflow is pretty nice but if the plugin can’t be managed by the Package Manger the whole project is a bit of a fail.
Cheers
DK
Everything works as expected if you manually install DKUI from the Package Manager:
Sample file attached.
Cheers
DK
250527_DKUI test.gh (7.4 KB)
OK, tried uploading my YAK with the name in a manifest renamed to DKUI.Components - but got a YAK error that the name in the Manifest cannot contain “.”
Poking around in the build file I found this in ProjectPlugin_Grasshopper.cs in the source folder:
public override string AssemblyName { get; } = "DKUI.Components";
public override string AssemblyVersion { get; } = "25.5.27.9279";
public override string AssemblyDescription { get; } = "A WebUI based, cross platform GUI builder for Grasshopper. Icons by https://icons8.com";
public override string AuthorName { get; } = "David Kay";
public override string AuthorContact { get; } = "karorocad@gmail.com";
public override GH_LibraryLicense AssemblyLicense { get; } = GH_LibraryLicense.unset;
public override SD.Bitmap AssemblyIcon { get; } = PluginIcon;
It looks to me as this is the source of the name confusion, is there a way to fix this in the Script Editor?
Cheers
DK
Hey Guys,
Its been 9 days since I started this thread and I’ve not had a reply from anyone at McNeel on it.
Would be great to get a:
“Opps yes, thats not right, we’ll look into it”
or even:
“Nah, we never intended for GH plugins written in GH to be managed by the Package Manager - you’ll need to make your users manually install”
Anyone out there in McNeel developer land able to shed some light on this issue? Anyone?
Cheers
DK
Hi David,
I’ve only done the local yak, i’ll try and repeat with your steps later in the day. This has been assigned to Eshan and he should pop his head up soon, he’s been in some deep work this week which is almost ready to commit.
Thanks Japhy, local drag/drop of the YAK file works FINE, the issue comes when sending a GH file that uses the plugin to a user that does not have it installed.
The package manager SHOULD find it and install it - but fails due to the names not matching.
Cheers
DK
PS - Actually REALLY happy with this Script Editor workflow for compiling Python based GH plugins, just need the last little bit to work…
@kiteboardshaper Hello and sorry for the late reply. I see the problem here is that Yak inside GH1 is looking for the yak plugin based on name of the assembly which is DKUI.Components
I created a YT issue to get this fixed ASAP
RH-87682 Published gh1 plugin with .Components in its name is not discoverable by Yak
As a workaround you can override the assembly name in the generated DKUI.Components project source and rebuild and repack the yak package to publish.
Thanks I’ll have a look at this @eirannejad - what software do I use to rebuild and repack .cs source? Can that be done in the Script Editor? I do have VS Code and VS on my machine but barely touch them…
Cheers
DK
@eirannejad thanks for the heads up.
I found and opened the .sln file in Visual Studio, then did a find/replace in the whole project - replacing DKUI.Components with DKUI then built for release.
The installed the resulting DKUI.GHA, opened my demo, saved it, uninstalled the GHA, opened my demo AND:
SUCCESS!
Bit of a extra step but nice to have a solution.
Cheers
DK
So this is more of a heads up related to the fix I am gonna put into next Rhino 8
The reason Grasshopper plugin assembly is named DKUI.Components is because script editor publishes Rhino and Grasshopper plugins into one package and Rhino plugin matches the name of the project e.g. DKUI in this case.
To avoid naming conflict between the two assemblies .Components is added to the GH1 plugin assembly.
I am going to make the Yak handler on Grasshopper 1 smarter so when it sees <name>.Components it searches for a package <name> as well.
This will resolve the problem without any monkey-patching of the solution after the project build. It is also backward compatible with all the plugins other developers have published as well.
@eirannejad that does sounds like the most logical solution - I’ll consider what I’m doing right now as part of the development process and look forward to seeing the system ready for production soon.
Can’t actually believe I’m the first person to run into this issue, the workflow has been been available for how long? 18 months?
Cheers
DK
Haahaha yes! You are definitely the first! I am working on this today and will update here when I have a solution
I investigated this a bit more. The yak package manager first tries to find the package based on the guid:* keyword. This keyword contains the assembly id of the dlls in the package.
I made a test plugin and pushed it to yak and tested that it can be installed with no issues
Would you mind confirming that the manifest.yaml contains a keyword formatted as guid:<plugin-id> in your package? It would also be great if you can DM me your yak package that has trouble being installed
Oh actually I downloaded your package from Package Manager and verified that it does not have the guid in the keywords:
keywords:
- DKUI
- HumanUI
- Synaspe
- ETOWebview
- User_interface
- GUI
- Grasshopper
Add those back please and publish 
- guid:3344a56f-c707-4b52-8f1d-66f39084ea4a
OK, this could be it, I’ll try that as soon as I’m into my office this morning.
Cheers
DK
Ehsan, you LEGEND! Thank you!
You are 100% correct - I had my custom manifest file looking like this:
---
name: DKUI
version: 25.5.28.3
authors:
- David Kay
description: A WebUI based, cross platform GUI builder for Grasshopper. Icons by https://icons8.com
license: ''
url: ''
keywords:
- guid:3344a56f-c707-4b52-8f1d-66f39084ea4a
icon: icon.png
keywords:
- DKUI
- HumanUI
- Synaspe
- ETOWebview
- User_interface
- GUI
- Grasshopper
I hadn’t noticed that the GUID was actually under a keywords: key, so ended up with keywords: TWICE.
Updated today to:
---
name: DKUI
version: 25.5.30.1
authors:
- David Kay
description: A WebUI based, cross platform GUI builder for Grasshopper. Icons by https://icons8.com
license: ''
url: ''
icon: icon.png
keywords:
- guid:3344a56f-c707-4b52-8f1d-66f39084ea4a
- DKUI
- HumanUI
- Synaspe
- ETOWebview
- User_interface
- GUI
- Grasshopper
AND:
GH is able to find and install perfectly.
Thank you.
BUT - this does bring up a request for the Script Compiler.
Can we please have the option to fill out more details for the manifest file than just what is available on this menu:
In particular project Icon, to be included in the .YAK file and a full set of keywords.
The current auto created manifest does not include these:
---
name: DKUI
version: 25.5.29+9282
authors:
- David Kay
description: A WebUI based, cross platform GUI builder for Grasshopper. Icons by https://icons8.com
license: ''
url: ''
keywords:
- guid:3344a56f-c707-4b52-8f1d-66f39084ea4a
So currently EVERYTIME I compile my plugin I’m:
Its a bunch of busy work that could/should just be part of the Script Editor setup for the project.
I could start a different thread on this feature request if needed?
Cheers
DK
Sweet. Ya I added a ticket to improve the publish dialog
RH-87711 Support adding more data to manifest.yaml