Platform Team/Guide/Sweets Packaging

From Sugar Labs
< Platform Team‎ | Guide
Revision as of 14:35, 30 September 2011 by FGrose (talk | contribs)
Jump to navigation Jump to search

Summary

This guide describes how to prepare software projects to be distributed via Sugar Labs' Packaging Management System, Sweets.

Make sure that you read the introduction page and Usage guide. To understand conceptual ideas, read the Glossary.

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

The command ./sweets upgrade might require relogin from the X session to take into account the new PATH value.

Writing recipe files

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:

These files need to be placed in the root sources directory with names sweets.recipe or activity/activity.info for Sugar activities.

Development with Sweets

Source bundles might be used on a client side not only indirectly, via sweets command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is no different from .xo files. To make sources useful within Sweets, the local directory with sources might be used in several cases:

  • Applications might be launched from sources, {{Code|sweets <path-to-sources>};
  • To reuse sources as dependencies for other sweets, 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 sdk/sugar.

Feedback


Retrieved from "https://wiki.sugarlabs.org/index.php?title=Platform_Team/Guide/Sweets_Packaging&oldid=69626"