Packaging extensions ↩

• GitHub Actions
• The extension is the source (legacy)
• Source and extension in the same repository (legacy)

With the release of the open-source RoboFont Extension Bundle module, packaging and distributing extensions has never been easier. This article will present the preferred method to package extensions and two older methods still supported.

GitHub Actions

GitHub Actions is a GitHub service that allows to easily build continuous integration (CI) and continuous deployment (CD) pipelines. In other words, through these actions we can run code on the GitHub servers following git events. It is possible to automatically handle releases and validate extensions. To achieve this result we need to follow a specific file structure:

http://github.com/user/myExtension ├─ .github/ │ └─ workflows/ │ └─ validate_build.yml ├─ info.yaml ├─ build.yaml └─ source/ ├─ lib/ │ └─ tool.py ├─ html/ │ └─ index.html └─ resources/ └─ image.png

A few notes:

• The info.yaml file replicates the info.plist content.
• The build.yaml stores the location to the source subfolders (lib, html and resources) and an optional path if it should be different from the extension name
• The validate_build.yml file contains the github action instructions.

Check the examples at the end of this section for some use cases.

Consider that following this pattern, it will not be necessary to track the bundle in the repository history. The validate_build.yml action will take care of building and releasing a new extension any time a commit contains a different version number in the info.yaml file (assuming the autotagging is set to true).

Advantages & disadvantages

advantages	disadvantages
build and release process is completely automated no duplication between bundle and source code no manual editing of info.plist	none, really

Examples

• Extension Boilerplate
• Single WindowController ruling over…
• Batch
• Outliner
• CornerTools

The extension is the source (legacy)

There is no separation between the extension source and the built extension: the code is written as an extension according to the Extension File Specification.

http://github.com/user/myExtension ├── myExtension.roboFontExt │ ├── lib/ │ ├── html/ │ ├── info.plist │ └── license ├── README.md └── license.txt

Workflow

1. Install the extension. The files will be copied into the plugins folder:

    /Users/username/Library/Application Support/RoboFont/plugins
   

2. If you need to make changes to the code, you can do it directly in the installed extension – so you can test the changes right away.

3. Once you’ve finished making changes, you can copy the modified files back into the source folder, overwriting the older files.

4. Follow the usual process to update the extension: add and commit your changes, and push to the remote server.

Advantages & disadvantages

advantages	disadvantages
no build process	working inside the plugins folder updating files manually

Source and extension in the same repository (legacy)

This scheme is common for extensions which are built with a script. The repository contains both the source files and the built extension.

The source files are used for development, the extension for distribution.

http://github.com/user/myExtension ├── source/ │ ├── code/ │ └── documentation/ ├── build/myExtension.roboFontExt │ ├── lib/ │ ├── html/ │ ├── info.plist │ └── license ├── README.md ├── build.py └── license.txt

Workflow

1. The code is developed as unpackaged source code by calling scripts directly.

2. When you are done making changes, run a build script to update the extension.

3. The generated extension can be installed for testing.

4. Follow the usual process to update the extension: add and commit your changes, and push to the remote server.

Advantages & disadvantages

advantages	disadvantages
source folder can be anywhere not necessary to work inside the plugins folder like Pattern 1	duplication of data in the same repository (source / extension)

Before the release of the open-source RoboFont Extension Bundle package, this article presented a different set of patterns. We decided to remove entirely pattern #3 “Source and extension in separate repositories” and pattern #4 “Multiple extensions in a single repository” as they are totally discouraged.