Once again it’s been a while since I’ve posted here so I wanted to give an update on the Rhino Package Manager. Thanks to those of you who came to hear about the project (amongst many other awesome things) at the Rhino New Developments Day in London back in April! Here’s what I’ve been working on over the last 2-3 months…
You can now un-list (“yank”) package versions if you want to hide specific versions from users. Yanked versions will not appear in the Package Manager UI (see below) or when searching via the Yak CLI. If you yank all versions of a package then the package itself will be hidden.
Automation and CI
A while ago we introduced NuGet packages for Rhino .NET SDK references. This was the first step in making it easier to build and test Rhino/Grasshopper plug-in projects using freely available CI services, like AppVeyor.
Automation is an important aspect of the Yak packaging and publishing process. Pull request #2 of @stevebaer’s GhCanvasViewport project demonstrates how you can deploy pre-release versions of a plug-in for each CI build.
To begin with, the project’s appveyor.yml defines a couple of new environment variables,
yak_package_version, where the former is a three-digit version number (i.e.
1.0.0) and the latter appends a SemVer-compatible “pre-release” suffix which contains the build number (i.e.
AppVeyor patches the
AssemblyInformationalVersion attributes using the using the
yak_package_version env vars. The
AssemblyInformationalVersion is the important one here because it allows us to inject a SemVer-compatible version string into the plug-in which is important for Grasshopper Package Restore.
Finally the packaging and publishing is handled by a deployment script. The script uses the
yak_package_version env var to set the
version field in the manifest.yml file (which has been added to the repo). Because the packaging process is so simple, we can use simply PowerShell’s built-in zip archive functionality to create the package. For publishing however, we need the Yak CLI. I compiled a special standalone version of yak.exe for use in deployment scripts. The script downloads the latest yak.exe and uses it to push the new package version using an API token that’s stored securely in the
YAK_TOKEN env var.
Searching for versions and stable vs pre-release
Yak is now more pre-release aware. Previously
yak search PATTERN would list the absolute latest versions of all packages that match
PATTERN. Now, Yak considers the latest version to be the latest stable version, unless there are no stable versions. If you want the old behaviour, you can use
yak search --prerelease PATTERN.
Sometimes it’s useful to see all of the available versions of a package.
yak search --all PATTERN will list all of the stable versions of a package. You can also use both flags together to list all versions of a package, i.e.
yak search --all --prerelease PATTERN.
The Package Manager UI is being updated to have the same distinction between pre-release and stable package versions.
Package Manager UI updates
@trav helped me prettify the UI ready for showing off at StF. We’ve also added some useful fields to the info pane, such as published date and project homepage, as well as the pre-release toggle mentioned above. The UI is still a work-in-progress and can be found via the
TestPackageManager command in Rhino WIP.
yak uninstallno longer fails if package is not installed/doesn’t exist
With the exception of the UI, all of this is available in Rhino 6 SR 7, released last week. Please check it out and ask questions!