Sugar Network/Recipe Specification
The recipe specification file is an analog of scenario files in regular GNU/Linux distributions, like .spec files in RPM. It is the cornerstone of Doers environment, everything on Sugar project level depends on the recipe file. For activities, activity.info, an inherited recipe file name, is supported.
Recipe structure
Recipe file is an ini format configuration file that might consist of several sections:
- One or more use case sections.
- Optional archive sections.
- Optional auxiliary sections.
- Optional
[DEFAULT]
section with common options that are accessible from all other sections.
Use case sections
Recipe should contain at least one use case section to describe how the sweet might be used.
Use case sections are named:
[use-case-type[:sub-name]]
Where use-case-type is one of the following sub sections and sub-name is an optional identifier used if there are more than one sections of the same type.
Regardless of the type, a use case section (or one of them) should contain the following options:
sweet = <identifier>
Required. An identifier of the sweet. Only lower alphabetic, numeric, "+", "-" or "." symbols are allowed. The sweet identifier should be at least two characters long and start with an alphanumeric character.
sweet is used in several cases:
- in 0isntall feed url -
http://sweets.sugarlabs.org/sweet
, - in native package names generated from the recipe.
Important note: The sweet is not intended to be unique. That means that there may be several implementations for the same sweet in the field. They might be different versions of the sweet from the same developer, or even separate implementations from other developers.
name = <name>
Optional. Free-form name. (It is equal to the sweet, by default.)
summary = <one-line-description>
Required. Short descriptive line.
description = <multi-line-description>
Optional. Long descriptive text. To wrap long text, all lines after the second, should start with spaces. This field is equal to summary by default.
license = <license-name>
Required. The license. Short license names from Fedora naming scheme are welcome.
homepage = <url>
Required. Sweet project home page.
icon = <icon-file-name>
Optional. Path to the icon file starting from the path where the recipe file is located.
category = <category> [; ...]
Optional. A classification for the sweet using values defined by freedesktop.org menu specification.
version = <version-number>
Required. Current version of the sweet using 0install version format. If the age option was set, versioning is a bit different.
stability = <stability-level>
Required. Stability level of the current version. Values conform to 0install stability levels and could be:
- insecure
- buggy
- developer
- testing
- stable
[Activity]
This component section type should be present only in activities.
activity_version = <version>
Required. Option is deprecated, use version instead, but should be still present to not fail in current sugar. It will be useful to use expansion like %(version)s
for this option.
bundle_id = <bundle-id>
Required. See activity.info file specification. Option is deprecated, use sweet instead, but should be still present to not fail in current sugar.
icon = <icon-file-name-without-suffix>
Required. Behaviour from activity.info is supported (value should not have ".svg" suffix, and icon file could be found only in activity subdirectory) but deprecated. Regular icon behaviour from [Component] section should be used instead.
exec = <shell-command>
Required. Sugar will pass additional command line arguments to this command.
mime_types = <mime-type> [; ...]
Optional. List of mime types supported by the activity. It's used when opening a file from the web, or to present to the user a list of activities that can open a certain Journal object.
tags = <tag> [; ...]
Optional. Tags give more context in which to group the activity. This is used to allow users to find activities more easily in the Journal, the Home view, etc.
requires = <dependency> [(=|>=|<) <version>] [; ...]
Optional. List of dependencies that should exist in run-time before launching the activity.
[Application]
Application to run out of Sugar Shell.
exec = <shell-command>
Required. The relative path of an executable command inside the implementation that should be executed by default when the sweet is run. Command can have optional arguments.
requires = <dependency> [(=|>=|<) <version>] [; ...]
Optional. List of dependencies that should exist in run-time before launching the application.
[Library]
age = <age-number>
Optional. Simple number that will be used as a major number for version, see versioning scheme for details.
binding = [prepend|append|replace] <variable-name> [<insert-text-to-prepend-variable-value>] [; ...]
Required. The environment variables 0install should export to the process that uses this sweet.
requires = <dependency> [(=|>=|<) <version>] [; ...]
Optional. List of dependencies the library is based on.
Archive sections
Archive section describes the tarball that will contain the sweet implementation.
If there are not any archive sections, the sweet implementation consists of only one archive that includes the entire %(DESTDIR)s
directory (excluding temporary files). At the same time, the sweet implementation might be split into several archives.
Possible use cases:
- To save storage space or bandwidth when some tarballs will contain any-arch data that are common for all platforms, and another tarball will contain binaries for a particular platform.
All archive sections are named:
[Archive[:sub-name]]
And contain the following options:
include = <glob-pattern> [; ...]
Optional. Glob pattern for files to include in the archive. Path related patterns will be processed starting from the %(DISTDIR)s/%(PREFIX)s directory. By default, all files are assumed.
exclude = <glob-pattern> [; ...]
Optional. Like the include option, but used for excluding files from the archive. In addition, various temporary files will be excluded, like .bak or .pyc.
langs = <lang-name> [; ...] include[<lang-name>] = <glob-pattern> [; ...] exclude[<lang-name>] = <glob-pattern> [; ...]
Optional. A special form of include/exclude options that are intended to create separate, per locale, archives. If a language is mentioned in the langs list, but doesn't have any include[]/exclude[] options, include/exclude will be used (in that case, using the special LANG variable makes sense).
arch = <arch>
Optional. Makes sense only for binary archives, and can contain:
- all for noarch (by default)
- any for binaries to use the current architecture
Auxiliary sections
Sections that don't describe recipe components.
[Build]
This section is required if the sweet needs additional work in order to prepare a ready-to-use installation. To prepare valid sweets, it is important to use predefined constants for options that contain shell commands. All shell commands will be executed from the %(BUILDDIR)s
directory.
NOTE The commands in this section will be executed, not only in the developer's environment, but also in the user's, if a proper binary wasn't found; so move all development-related commands, like autogen.sh
, to the [Source] section.
requires = <dependency-name> [(=|>=|<) <version>] [; ...]
Optional. This defines what dependencies should be present before building the sweet from sources. Note that requires from [Component] sections are not auto included in the build-time dependencies.
clean = <shell-command>
Optional. Cleanup build environment before running configure command.
configure = <shell-command>
Optional. Shell command to configure sources before building, e.g., invoking the configure script in auto-tools-based projects. If the source code does not require a configuration stage, this option could be omitted.
make = <shell-command>
Optional. Shell command to make binaries from sources. If the source code does not require a making stage, this option could be omitted.
install = <shell-command>
Required. Shell command to place files that are ready for distribution into the %(DESTDIR)s
directory. If install is missing, the entire %(BUILDDIR)s
(excepting temporary files) will be copied.
[Source]
How to create sources tarball. Options make sense only in the developer's environment.
url = <url>
While packaging 3rd-party applications, url to download sources tarball.
patch = <path-to-patch> [patch-level] [; ...]
If source option is used, 3rd-party sources might be patched.
exec = <shell-command>
Execute external program to create sources tarball. Option might be used, e.g., to run make dist
command. After executing the exec shell command, sweets
will pick up newly appearing tarball if it was created in the sweet root directory.
include = <glob-pattern> [; ...] exclude = <glob-pattern> [; ...]
If neither url nor exec options were used, all files will be bundled and these glob patterns might be used to concretize the selection.
requires = <dependency> [(=|>=|<) <version>] [; ...]
The dependencies that should be present before creating sources tarball. For example, if the exec command generates .c files from .vala, the vala dependency should be mentioned in the requires option.
Predefined options
Options defined within [Build] section:
- BUILDDIR where the build happens, directory contains untarred sources bundle. This variable can be used in binding options as well. During the local build, it will point environment variables to the root of sources directory.
- DESTDIR temporary path to place installed files before bundling them
- PREFIX should be used as installation prefix path, e.g., for
./configure --prefix
- CFLAGS default gcc CFLAGS
- CXXFLAGS default gcc CXXFLAGS
In sections that contain a langs option:
- LANG current language while building per language implementation
Examples
Python activity
Python-based activity with standard Sugar Platform dependencies.
[Activity] sweet = cartoon-builder name = Cartoon Builder summary = Create your own cell-animation sequences license = GPLv2+ homepage = http://wiki.sugarlabs.org/go/Activities/Cartoon_Builder icon = activity/activity-cartoonbuilder.svg version = 11.4.9-pre3 stability = testing exec = sugar-activity activity.CartoonBuilderActivity
Python library
A python-based library that could be used as is, or as an activity dependency.
[Library] sweet = libjournal summary = Hight level library to create your own Journal-like activity license = GPLv3+ homepage = http://wiki.sugarlabs.org/go/Activity_Team/Services/Journal version = 1 stability = testing requires = toolkit binding = PYTHONPATH
C-based library
[Library] sweet = polyol summary = Intermediate level GObject based libraries for Sugar description = Polyol is a set of libraries that are written in Vala. Libraries are intended to provide high-level C API to basic Sugar features including Gtk based user interface. Applications that are linked against Polyol, interact with sugar processes (like shell, datastore, etc.) via DBus. license = LGPLv3+ homepage = http://wiki.sugarlabs.org/go/Activity_Team/Polyol age = 0 version = 1 stability = testing binding = LD_LIBRARY_PATH lib PKG_CONFIG_PATH lib/pkgconfig VAPIDIR share/vala/vapi requires = glib; gconf; libgee >= 0.5; gtk+ >= 2.12; pango >= 1.20; librsvg [Archive] arch = any [Build] requires = %(depends)s; pkg-config; cmake; make; gcc-c configure = cmake -D CMAKE_INSTALL_PREFIX=%(PREFIX)s -D PYTHON_SITEDIR=%(PREFIX)s/python -D COMPONENTS="collab;ds;env;gui;shell;toolkit" -D BINDING=python -D CMAKE_C_FLAGS:STRING="%(CFLAGS)s" . make = make install = make DESTDIR=%(DESTDIR)s install