Hey McNeel team, I want to make a feature request for Yak/package manager. Often I find myself wanting to load different sets of plugins for different workflows. For example, I only need a couple Grasshopper plugins loaded when I’m developing my own plugins, but for other work I might need a much bigger set. Can we get custom profiles added to package manager? Ideally also something that could be triggered through Visual Studio debug profiles with an argument to rhino.exe (like /nosplash).
Hey @colinlsmatthews,
Let’s explore this idea, my first question is, why? Is Rhino or Grasshopper slow? Is it something else an issue with all the plugins?
Hey @CallumSykes, thanks for the quick response. There are two reasons, I suppose:
- Yes, speed. Shaving a few seconds or so off the loading time for Rhino/GH is a nice plus when debugging with an external IDE.
- General cleanliness and compartmentalization. I wear many hats in my role. Some days I’m a ladybug guy; other days I’m helping with complex geometry. I don’t need all my plugins every day, but I need them often enough that uninstalling and reinstalling individual plugins is impractical. Being able to load a task-specific suite of plugins would keep the Grasshopper UI from getting cluttered with dozens of plugin icons.
My workaround for this up until this point has been to just copy/paste into %APPDATA%\Grasshopper\Libraries from two plugin folders on the desktop: GH_Dev and GH_Work. I suppose I could do that same with %APPDATA%\McNeel\Rhinoceros\packages\8.0, but it’s not a very elegant solution from a UX perspective. I feel like the package manager should manage packages for me, not vice versa.
Before using the package manager, I also had an incentive to keep a million plugins installed at all times to avoid missing .gha errors when sharing and receiving files with colleagues. With yak-hosted plugins that’s not an issue anymore, so I would love to simplify my workspace and only load what I need when I need it.
One more thought, these theoretical yak profiles could also be associated with the license holder as opposed to the local installation, which would allow users to configure plugins universally no matter what machine they are using.
I’ve been mulling this request for a while @colinlsmatthews and the best way to implement it. I’ve even considered doing this as a hackathon project before because I like the idea (But I was only thinking GH, all plugins is smarter).
I’ve logged it as an issue so we can get more eyes and discussions on this. I can say this wouldn’t be in 8.x and unlikely in 9.x however.
I normally like to post youtrack links but it seems like something where we might need to discuss things more technically so unsure if I can post yet 
1 Like
- General cleanliness and compartmentalization. […]
I second this. Having to clean up a GH file from third party components, in order to share it with people who don’t have or cannot have those installed, can get tedious.
Awesome! @CallumSykes I’m glad to hear my request fell on fertile soil. If this ever does make it to youtrack, please let me know. I would love to follow, and contribute if possible.
@Bernd_Möller I wrote a little utility script in my GH template that can check a file for yak compatibility. Maybe you’ll find it useful:
2 Likes
It’s on YouTrack, but not currently public, just for now