The Package Manifest
What is a 'package manifest' and what should it include?
Each package should have a manifest file containing a spec that can be distilled into the database when the package is pushed to the server. The manifest should be written in YAML, following the structure of the example below.
The manifest file should be named
manifest.yml and should live in the root of the package. (Don’t worry, the Yak CLI tool’s
build command takes care of this for you!)
The manifest’s purpose is to help with streamlining (and potentially automating) the process of releasing packages, removing the need for any web forms when publishing packages.
Here’s an example for a Grasshopper plug-in.
name: plankton version: 0.3.4 authors: - Daniel Piker - Will Pearson description: > Plankton is a flexible and efficient library for handling n-gonal meshes. Plankton is written in C# and implements the halfedge data structure. The structure of the library is loosely based on Rhinocommon's mesh classes and was originally created for use within C#/VB scripting components in Grasshopper. url: "https://github.com/meshmash/Plankton"
The short name describing the package. Preferably one world although multiple words can be separated by underscores or hyphens.
Note: Package name can only include letters, numbers, dashes, and underscores
Note 2: Package names adopt the case used in the very first version that was uploaded. Future uploads ignore the case of the package name and all queries are case-insensitive.
Since 0.8: four-digit version numbers allowed
The version number given to the package.
Package version numbers must either follow Semantic Versioning 2.0.0 (e.g.
System.Version a.k.a. Microsoft’s four-digit standard (e.g.
22.214.171.124). It’s recommended to use Semantic Versioning because it allows package authors to specify prerelease versions. These are handy for limited testing, since by default the latest stable version is installed.
To make the authoring process easier, it’s possible to replace the version number with
$version – the version number will be inferred from the contents of the package and substituted during
A list of author(s) of the package.
authors: - Daniel Piker # list additional package authors below - Will Pearson
Describe the package. Be as in-depth or as brief as you feel is appropriate.
description: This is an awesome package.
If you want to write more, you can use use YAML’s folded style.
description: > This is such an awesome package that I'm going to write a whole bunch of text describing it!
A webpage for the package. This can be any URL i.e. author contact info, forums, tutorials or any other information about the plugin.
A list of keywords that will help users to find the package.
keywords: - one - two
Specify a link to an icon that will be used by the Package Manager in Rhino. Keep it small – a 32x32 PNG is ideal.