Platform Team/Guide/Sweets Packaging
- 1 Summary
- 2 Prepare the environment
- 3 Recipe files
- 4 Releasing
- 5 Development with Sweets
- 6 Developing activities
- 7 Good practices
- 8 Feedback
This guide describes how to prepare software projects to be distributed via Sugar Labs' Packaging Management System, Sweets.
Prepare the environment
Using the Usage guide's instructions, install the Sweets. In addition, Sweets might be used from sources:
git clone git://git.sugarlabs.org/sdk/sweets.git cd sweets git submodule init git submodule update ./sweets upgrade
./sweets upgrade might require relogin from the X session to take into account the new PATH value.
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 Sweets, everything on the sweet project level depends on the recipe file. For activities,
activity/activity.info, an inherited recipe file name, is supported.
On a logical level, the entire Sweets infrastructure might be treated as a set of distribution bundles with sources that contain recipe files. Software projects are identified as Zero Install interfaces that contain information about which distribution bundle needs to be downloaded in order to launch a particular software version. That's not the full picture (there are binary bundles created based on sources), but it is useful for this topic's purpose. Read the Development with Sweets section to learn about the available usage scenarios.
A 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.
[DEFAULT]section with common options that are accessible from all other sections.
These files need to be placed in the root sources directory with names
activity/activity.info for Sugar activities.
In sources directory, create a recipe file, e.g., using
sweets init command. Recipe file should contain at least one use case section. There are several types of use case sections:
- Activity for Sugar activities,
- Application for stand alone applications,
- Library for libraries.
Make sure that all required options were set. The implement option has a special meaning, it is an identifier of the sweet.
By default, the entirely sources directory will be packaged into sources tarball. In case if sources list needs to be restricted, add Source section with appropriate include and/or exclude options.
If the sweet needs to be built, add Build section.
If built files are platform dependent, add Archive section with arch=any option.
The implement, associate and requires (optionally) options contain short interfaces. These values have two meanings:
- suffixes for final interfaces, e.g.,
- the name of project/package on OBS that will be used to host released sweet.
In the 2nd case, the last slash separated part is a package, and the rest is a project, e.g., for sdk/sugar, sdk is a project and sugar is a package in the sdk project. It is possible to have interface values without slashes, in that case, project and package names are the same.
In the OBS, there is a special project named base. This project contains sweets that all time will be represented only by native packages. In other words, if you need to make sure that your sweet needs to depend only on native packages, use dependencies from the base project.
The base project is also useful for associated interfaces set in associate recipe option. For example, if your sweet needs pygame=2 dependency that is not yet widespread, create ~user/pygame temporary sweet with 2 version only, and use ~user/pygame as a dependency in your sweet. If base/pygame will be added as associated interface to the ~user/pygame, users that have >=2 version in native packages will reuse them instead of ~user/pygame's one.
See OBS projects for all existed sweets.
Dependencies might be used in the requires and suggests options in recipes files to declare that the current sweet depends on another sweet/s.
The format of a dependency string is:
<interface> [(=|>=|<) <version>]
The interface value supports all interface forms. The limited set of version conditions depends on Zero Install specification when the
= condition is a high level one and will be described in
Dependencies may be optional. In that case, they need to be wrapped in square brackets. Optional dependencies will be used only if there is an implementation to choose, otherwise they will be discarded without errors.
Sweets should have stability status:
- stable, final stable release,
- testing, let people interested in testing try latest changes that are not yet stable,
- developer, just a more extreme version of testing,
This is a useful Zero Install feature that let developers share not yet stable version among the community. Since by default, only stable versions are being used, people, who are interested in helping developers in polishing not yet stable versions, need to explicitly choose not stable versions.
The include and exclude options contain file patterns. A pattern could be of two types:
- doesn't contain / or ** substrings, will be applied only to file names
- contains / or ** substring, will be applied to the full file path (relative to the root), thus could affect several directory levels
Only these pattern symbols are allowed:
- * matches everything, except directory separator
- ? matches any single character, except directory separator
- ** matches everything, including directory separator
A list of recipe examples. Additionally, see
sugar* repositories in the Gitorious sdk repository, all of them are sweets.
Python-based activity with standard Sugar Platform dependencies.
[Activity] implement = cartoon-builder name = Cartoon Builder summary = Create your own cell-animation sequences license = GPLv2+ homepage = http://wiki.sugarlabs.org/go/Activities/Cartoon_Builder version = %(activity_version)s stability = stable icon = activity-cartoonbuilder exec = sugar-activity activity.CartoonBuilderActivity # Backwards compatibility of original activity.info options bundle_id = com.ywwg.CartoonBuilderActivity activity_version = 7
A python-based library that could be used as is, or as an activity dependency.
[Library] implement = libjournal name = 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
[DEFAULT] depends = base/glib; base/gconf; base/libgee >= 0.5; base/gtk+ >= 2.12 base/pango >= 1.20; base/librsvg [Library] implement = polyol name = 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 version = 1 stability = developer binding = LD_LIBRARY_PATH lib PKG_CONFIG_PATH lib/pkgconfig VAPIDIR share/vala/vapi requires = %(depends)s [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
In Sweets, releasing means uploading a sources tarball with a release (though, that doesn't only mean stable versions) to the Sugar Labs instance of the Open Build Service (OBS). Before releasing, make sure that you have a Sugar Labs account. A login with password will be required the first time or when your cookie is missing.
Before releasing, make sure that your recipe conforms to the OBS Policy. While releasing, sweet sources will be uploaded to an OBS project/package according to the implement recipe option. If a particular project or package don't exist, they will be created (upon user's confirmation for project creation).
To initiate releasing, enter from the sweet sources directory:
sweets command will ask for a commit message, i.e., release notes. The same notes might be passed to
commit command via the
--message command-line argument.
If the releasing sweet is binary based, only the most recent stable version will be built on the OBS side, other versions will be built on the client side.
Development with Sweets
Source bundles might be used on the client side not only indirectly, via
sweets command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is just like
.xo files. To make sources useful within Sweets, the local directory with sources might be employed in several ways:
- Applications might be launched from sources,
- To reuse sources as dependencies for other sweets, the source directory needs to be registered in Sweets,
sweets checkout <path-to-sources>; applications might be checked out as well.
Checking out will register a sweet in the local Sweets instance as a single implementation for the interfaces it implements. This feature is especially useful for libraries, for example, if the sugar-toolkit sources, which implement the
sdk/sugar-toolkit interface, were cloned to the
~/src/sugar-toolkit directory, then, while running a
sdk/sugar sweet, it would become possible to reuse local sugar-toolkit sources as a regular implementation of the
sdk/sugar-toolkit dependency of
There are sdk/sugar sweets that might be used as an example how to support sweets. Sweets Sugar sources are always rebased forks of upstream projects with added
sweets.recipe files and lightweight patches that make the original code useful via Sweets.
Checkout sources from:
and see its
How Sweets might be useful while developing activities.
The traditional development related routine for activity sources is to run the
setup.py script located in the root activity directory. With Sweets, these routines might be accomplished with the
sweets command. Here is some background information:
- A downside of using Sweets is that running
setup.pyrequires being in the Sugar session (in order to have all the libraries that
- Sweets is designed to support multiple software versions at the same time. So to avoid having to login to different Sugar sessions for creating source tarballs, for example, it makes more sense to have a standalone utility;
sweetscommand already contains development related functionality; it is useful to keep all development related functions in one utility.
Sweets support the following
build, build generated files, e.g.,
dist_xo, create a .xo with activity sources;
dist_source, create activity sources tarball;
genpot, generate the gettext pot file.
And doesn't support the following:
dev- seems to be a needlessly exaggerated function that creates a symbolic link in the
~/Activitiesdirectory to activity sources. The same might be done using the
ln -scommand to avoid having derived functionality, or better, place sources directly in the
fix_manifest- function creates
MANIFESTfile. Not having this file is not a failure, and Sweets is designed to have include/exclude rules in recipe files instead;
install- function installs the activity to the root system. Sweets avoid, by design, any global changes during its regular behaviour.
sweets's commands, these commands need to be executed from the activity directory (or in any of its sub-directories, not just in the root), or the path to activity sources might be specified after the command name, e.g.:
sweets build [PATH]
Before starting Sugar Shell, place your activity's sources directory under the
~/Activities/ directory, or place there a symbolic link to the activity sources. After running Sugar Shell, the new activity will appear in the Home view (if it's absent in the Favorites view, switch to the List view).
It is common practice in binary-based GNU/Linux distributions to use satellite devel packages to collect various build-time files like C headers or pkg-config files. In the Zero Install environment, this doesn't work, because every package is stored in a separate directory hierarchy, e.g., *.so symlinks, from devel package, will point to nothing, since all *.so.* files from the library package live in a separate directory.
Keep all build-time files in the sweet with runtime files.
Library sweets that are associated with native packages (
base/* sweets), should use regular environment variables for binding, such as
LD_LIBRARY_PATH. The idea is that it should be possible to replace them with native packages transparently and avoid changes in sweets that use these libraries.