The RoboFont extension landscape is very diverse: different developers have different preferences and different levels of skill; functionality provided by extensions varies from simple scripts to complex RoboFont-based applications.

There is not one single pattern for packaging RoboFont extensions.

This page gives an overview of possible packaging patterns found in existing extensions.

1. The extension is the source

This is the simplest and most widely used scheme. 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

Examples

2. Source and extension in the same repository

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)

Examples

3. Source and extension in separate repositories

Same as Pattern 2, but with source files and extension separated in two repositories.

http://github.com/user/myExtensionSource ├── code/ ├── documentation/ ├── README.md ├── build.py └── license.txt

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

Workflow

Same as Pattern 2, but with separate commit histories for source and extension.

  • The source repository is the primary one, and includes the complete commit history.

  • The extension repository is secondary, its commit history shows only the ‘squashed’ changes between versions.

This pattern is recommended for binary extensions – the source repository is private, and the extension repository contains only the binary files for distribution.

Advantages & disadvantages

advantages disadvantages
  • no code duplication in the same repository, cleaner commit history
  • source repository can be used by itself as a module
  • two separate repositories to maintain and update

Examples

4. Multiple extensions in a single repository

This approach can be found in older extensions, and is now discouraged.

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

Workflow

Same as Pattern 1.

advantages disadvantages
  • centralized workflow, only one repository to update and maintain
  • not modular, commit history shows changes to different projects

Examples

Last edited on 15/07/2021