OK, so I’m experimenting with solutions for another person, which has actual domain knowledge, and so I configure GrassHopper definitions which I want him to try out. But… Sometimes such experimental definitions contains some other third-party Plugin which the receiver doesnt have installed. Hence my question:
Wouldn’t it make life easier to many of us if one could simply “Bake” all components being used in a definition into a definition that would be “selfcontained” and executable even if the user doesn’t have all the complete plugin-packages installed?
Although some Plugins requires license etc, that could be checked on Bake (allow only free components, or give the baked definition a grace period of N number of days).
Lets call them Bricked since you don’t change a bricked definition once being “Baked”.
I wouldn’t use the word bricked, as it is commonly associated with broken hardware. A bricked phone doesn’t work. When I read the title for this thread I first thought you had a broken definition, i.e. you did something, now it is bricked.
This is not a good solution. The real solution is to make it easy to install plugins when a file is loaded that needs them. Yak is the first step towards this, and would actually work already if we hosted more plugins on the Yak servers.
@will what is the timeline/roadmap for making the Yak repository inclusive enough so that it actually works?
It’s all there in the BETA, albeit in a raw state. I’m just not ready to broadcast it yet. The current plan is to release it more openly shortly after Rhino 6 ships and as it gains traction I’ll continue to tweak it alongside Rhino’s service releases.
@RIL, I’ll invite you to the “inner circle” so you can see what Yak-stuff I’ve pushed out so far.
“Freighter makes it easy to share your computational design tools with other users. Freighter provides utilities for the automatic packaging and launching of Grasshopper definitions, Rhino files, and other important dependencies.”
