# The Package Manifest

What is a 'package manifest' and what should it include?

## Overview

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.

Required Attributes

Recommended Attributes

## Example

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"


## Required Attributes

### Name

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.

name: plankton


### Version

Since 0.8: four-digit version numbers allowed Since 0.9: $version placeholder The version number given to the package. Package version numbers must either follow Semantic Versioning 2.0.0 (e.g. 1.1.0-beta) or System.Version a.k.a. Microsoft’s four-digit standard (e.g. 1.2.3.4). 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 yak build.

version: 0.3.4


### Authors

A list of author(s) of the package.

authors:
- Daniel Piker
# list additional package authors below
- Will Pearson


### Description

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!


### URL

A webpage for the package. This can be any URL i.e. author contact info, forums, tutorials or any other information about the plugin.

url: "https://github.com/meshmash/Plankton"


### Keywords

A list of keywords that will help users to find the package.

keywords:
- one
- two


## Optional Attributes

### Icon URL

Specify a link to an icon that will be used by the Package Manager in Rhino. Keep it small – a 32x32 PNG is ideal.

icon_url: "https://example.com/path/to/icon.png"