Changes

== Prepare the environment ==

== Prepare the environment ==

Using [[Platform_Team/Guide/Sweets_Usage#Installation|Usage guide]]'s instructions, install the Sweets. In addition, Sweets might be used from sources:

Using the [[Platform_Team/Guide/Sweets_Usage#Installation|Usage guide]]'s instructions, install the Sweets. In addition, Sweets might be used from sources:

  git clone git://git.sugarlabs.org/sdk/sweets.git

  git clone git://git.sugarlabs.org/sdk/sweets.git

== Writing recipe files ==

== Writing recipe files ==

The recipe specification file is an analog of scenario files in regular GNU/Linux distributions, like {{Code|.spec}} files in RPM. It is the cornerstone of Sweets, everything on sweet project level depends on the recipe file. For activities, {{Code|activity/activity.info}}, an inherited recipe file name, is supported.

The recipe specification file is an analog of scenario files in regular GNU/Linux distributions, like {{Code|.spec}} files in RPM. It is the cornerstone of Sweets, everything on the sweet project level depends on the recipe file. For activities, {{Code|activity/activity.info}}, an inherited recipe file name, is supported.

On logical level, the entirely Sweets infrastructure might be treated as a set of distribution bundles with sources that contain recipe files. Software projects are identified by Zero Install ''interfaces'' that contain information what distribution bundle need to be downloaded to launch particular software version. That's not the full picture (there are binary bundles created basing on sources), but it is useful for this topic's purpose. Read the [[#Development with Sweets|Development with Sweets]] section to know about possible usage scenarios.

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|Development with Sweets]] section to learn about the available usage scenarios.

Recipe file is an [http://docs.python.org/library/configparser.html ini] format configuration file that might consist of several sections:

A recipe file is an [http://docs.python.org/library/configparser.html ini] format configuration file that might consist of several sections:

* One or more [[Platform_Team/Recipe_Specification#Use case sections|use case sections]].

* One or more [[Platform_Team/Recipe_Specification#Use case sections|use case sections]].

* Optional {{Code|[DEFAULT]}} section with common options that are accessible from all other sections.

* Optional {{Code|[DEFAULT]}} section with common options that are accessible from all other sections.

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

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

== Development with Sweets ==

== Development with Sweets ==

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

Source bundles might be used on a client side not only indirectly, via {{Code|sweets}} command for example, but also explicitly. Sources might be bundled, emailed, etc. In this case, it is no different from {{Code|.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>''};

* 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, {{Code|sweets checkout ''<path-to-sources>''}}; applications might be checked out as well.

* To reuse sources as dependencies for other sweets, source directory needs to be registered in Sweets, {{Code|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 ''interfaces'' it ''implements''. This feature is especially useful for libraries, for example, if the sugar-toolkit sources, which implement the {{Code|sdk/sugar-toolkit}} ''interface'', were cloned to the {{Code|~/src/sugar-toolkit}} directory, then, while running a {{Code|sdk/sugar}} ''sweet'', it would become possible to reuse local sugar-toolkit sources as a regular ''implementation'' of the {{Code|sdk/sugar-toolkit}} dependency of {{Code|sdk/sugar}}.

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 {{Code|sdk/sugar-toolkit}} ''interface'', were cloned to the {{Code|~/src/sugar-toolkit}} directory, then, while running a {{Code|sdk/sugar}} ''sweet'', it would become possible to reuse local sugar-toolkit sources as a regular ''implementation'' of the {{Code|sdk/sugar-toolkit}} dependency of {{Code|sdk/sugar}}.

== Feedback ==

== Feedback ==