Das Paketmanifest

von Will Pearson (Zuletzt aktualisiert:  Mittwoch, 21. Juli 2021)

Übersicht

Jedes Paket sollte eine Manifestdatei mit einer Spezifikation haben, die in die Datenbank destilliert werden kann, wenn das Paket auf den Server übertragen wird. Das Manifest sollte in YAMLgeschrieben sein und der Struktur des untenstehenden Beispiels folgen.

Die Manifestdatei sollte den Namen manifest.yml tragen und sich im Stammverzeichnis des Pakets befinden. (Keine Sorge, der build-Befehl des Yak-CLI-Tools erledigt das für Sie!)

Der Zweck des Manifests besteht darin, den Prozess der Veröffentlichung von Paketen zu rationalisieren (und möglicherweise zu automatisieren), so dass bei der Veröffentlichung von Paketen keine Webformulare mehr erforderlich sind.

Erforderliche Attribute

Empfohlene Attribute

Beispiel

Hier ist ein Beispiel für ein 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"

Erforderliche Attribute

Name

Der Kurzname, der das Paket beschreibt. Vorzugsweise ein Wort, wobei mehrere Wörter durch Unterstriche oder Bindestriche getrennt werden können.

Hinweis: Der Paketname darf nur Buchstaben, Zahlen, Bindestriche und Unterstriche enthalten

_Hinweis 2: Die Paketnamen übernehmen die Groß-/Kleinschreibung, die in der allerersten hochgeladenen Version verwendet wurde. Künftige Uploads ignorieren die Schreibweise des Paketnamens und alle Abfragen sind unabhängig von der Groß- und Kleinschreibung.

name: plankton

Version

Seit 0.8: vierstellige Versionsnummern erlaubt Seit 0.9: $version Platzhalter

Die Versionsnummer, die dem Paket gegeben wurde.

Paketversionsnummern müssen entweder Semantic Versioning 2.0.0 (z.B. 1.1.0-beta) oder System.Version, auch bekannt als Microsofts vierstelliger Standard (z.B. 1.2.3.4), folgen. Es wird empfohlen, Semantic Versioning zu verwenden, da es Paketautoren erlaubt, Vorabversionen anzugeben. Diese sind praktisch für begrenzte Tests, da standardmäßig die neueste stabile Version installiert ist.

Um den Erstellungsprozess zu vereinfachen, ist es möglich, die Versionsnummer durch $version zu ersetzen - die Versionsnummer wird aus dem Inhalt des Pakets abgeleitet und während yak build ersetzt.

version: 0.3.4

Autoren

Eine Liste der Autoren des Pakets.

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

Beschreibung

Beschreiben Sie das Paket. Seien Sie so ausführlich oder so kurz, wie Sie es für richtig halten.

description: This is an awesome package.

Wenn Sie mehr schreiben wollen, können Sie den folded style von YAML verwenden.

description: >
  This is such an awesome package
  that I'm going to write a whole
  bunch of text describing it!

  This sentence will be on a new line.

URL

Eine Webseite für das Paket. Dies kann eine beliebige URL sein, z.B. Kontaktinformationen des Autors, Foren, Tutorials oder andere Informationen über das Plug-in.

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

Stichwörter

Eine Liste von Schlüsselwörtern, die den Nutzern helfen, das Paket zu finden.

keywords:
- one
- two

Symbol

Eine Bilddatei im Paket. Sie sollte klein sein (z.B. 64x64) und muss entweder ein PNG oder ein JPEG sein.

icon: icon.png

Veraltete Attribute

Symbol-URL

Wichtig
⚠️ Ersetzt durch das Attribut icon .

Geben Sie einen direkten Link zu einem Symbol an, das vom Paketmanager in Rhino verwendet werden soll. Es sollte klein sein (32x32 ist ideal) und muss entweder ein PNG- oder ein JPEG-Format sein.

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