Packaging extensions ↩
- 1. The extension is the source
- 2. Source and extension in the same repository
- 3. Source and extension in separate repositories
- 4. Multiple extensions in a single repository
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
-
Install the extension. The files will be copied into the plugins folder:
/Users/username/Library/Application Support/RoboFont/plugins
-
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.
-
Once you’ve finished making changes, you can copy the modified files back into the source folder, overwriting the older files.
-
Follow the usual process to update the extension: add and commit your changes, and push to the remote server.
Advantages & disadvantages
advantages | disadvantages |
---|---|
|
|
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
-
The code is developed as unpackaged source code by calling scripts directly.
-
When you are done making changes, run a build script to update the extension.
-
The generated extension can be installed for testing.
-
Follow the usual process to update the extension: add and commit your changes, and push to the remote server.
Advantages & disadvantages
advantages | disadvantages |
---|---|
|
|
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 |
---|---|
|
|
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 |
---|---|
|
|