The Anatomy of a Package
This guide explains the structure of a Yak package.
Packages are simply ZIP archives. Take this simple example…
howler-0.4.0.zip ├── manifest.yml ├── Howler.rhp ├── Howler.rui ├── HowlerCommon.dll ├── HowlerGrasshopper.gha └── misc/ ├── README.md └── LICENSE.txt
Important Things to Note
- Packages must have a top-level
manifest.ymlfile. Details about the manifest can be found in the Manifest Reference Guide.
- Any plug-ins (
.ghpyfiles) must be in the top-level directory so that Rhino and Grasshopper can find and load them
- Each package should have only one plug-in (
.ghpy). It is possible to combine plug-ins in one package (e.g.
.rhp) however package restore will only work for the plug-in which matches the details in the
- Versioning is critical to package management. The version number given to the package must adhere to SemVer 2.0.0. We’ve adopted SemVer to make ordering straightforward and also for easy identification of pre-release versions – handy when releasing beta plug-ins for limited testing! Please ask any questions about versioning on the Yak Forum.
- If you’re packaging a
.ghaplug-in, you should ensure that the package name and version number in the
GH_AssemblyInfosub-class match those in the
manifest.ymlfile, otherwise package restore may not work
Now that you’ve have seen what is in a package, why not create a package: