Difference between revisions of "Platform Team/Guide/Sweets Packaging"

From Sugar Labs
Jump to navigation Jump to search
Line 1: Line 1:
−
This guide describes how to use Sugar Labs' Packaging Management System to distribute software projects. See also the [[Platform_Team/Sweets|introduction page]] and [[Platform_Team/Guide/Sweets_Usage|Usage guide]].
+
== Summary ==
  
−
== Run Sweets from sources ==
+
This guide describes how to prepare software projects to be distributed via Sugar Labs' Packaging Management System, Sweets.
  
−
In addition to the [[Platform_Team/Guide/Sweets_Usage#Install|bundle install]], running from sources will be useful for people who prefer to use recent {{Code|sweets}}.
+
Make sure that you read the [[Platform_Team/Sweets|introduction page]] and [[Platform_Team/Guide/Sweets_Usage|Usage guide]]. To understand conceptual ideas, read the [[Platform_Team/Sweets/Glossary|Glossary]].
  
−
* Clone sweets sources and install it (after the first run, you need to relogin to take into account the new PATH value, then just run {{Code|sweets}} command):
+
== 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:
  
 
  git clone git://git.sugarlabs.org/sdk/sweets.git
 
  git clone git://git.sugarlabs.org/sdk/sweets.git
Line 13: Line 15:
 
  ./sweets upgrade
 
  ./sweets upgrade
  
−
== Development workflow with sweets ==
+
The command {{Code|./sweets upgrade}} might require relogin from the X session to take into account the new PATH value.
  
−
During the first launch, sources will be auto-built and kept in internal storage. To make sweets useful for development, checkout the development project sources in sweets:
+
== Writing recipe files ==
  
−
sweets checkout [''path-to-sources'']
+
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.
  
−
<!-- is the path-to-sources argument optional? If not, no square brackets. -->
+
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.
  
−
The only thing that is required from sources is having a [[Platform Team/Recipe Specification|sweets.recipe]] spec file for non-activity projects or an {{Code|activity/activity.info}} file (that conforms to the same spec) for activities. All sweets for Glucose components are located in the http://git.sugarlabs.org/sdk project.
+
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]].
 +
* Optional [[Platform_Team/Recipe_Specification#Archive sections|archive sections]].
 +
* Optional [[Platform_Team/Recipe_Specification#Auxiliary sections|auxiliary 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.
  
−
Once checked out, these sources might be launched using {{Code|<nowiki>http://</nowiki>sweets.sugarlabs.org/''sweet-value-from-sweets.recipe''}} or just mentioning a sweet value:
+
== Development with Sweets ==
  
−
sweets ''sweet''
+
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:
  
−
For glucose projects, you can find ready-to-use and always-rebased-to-upstream projects in the [http://git.sugarlabs.org/sdk SDK] http://git.sugarlabs.org project. For now, there are two branches: {{Code|master}} for recent trunk, and {{Code|master-0.88}} for 0.88 code based on Dextrose-2 patches.
+
* 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.
  
−
Checked-out projects will be built according to the {{Code|[Build]}} section commands in the {{Code|sweets.recipe}} files. In general, for autotools-based projects, there is no further need for the {{Code|sweets}} command; just run {{Code|make install}} to build current sources and install  them to the directory that was specified by {{Code|sweets}} in the configure stage. For glucose projects, there is no need even in calling the {{Code|make}} command (python code will be reused from its original location, see {{Code|binding}} options in [[Platform Team/Recipe Specification|sweets.recipe]] files), just change the code and restart sugar.
+
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}}.
  
 
== Feedback ==
 
== Feedback ==
Line 37: Line 47:
  
 
<!--
 
<!--
 +
 +
The only thing that is required from sources is having a [[Platform Team/Recipe Specification|sweets.recipe]] spec file for non-activity projects or an {{Code|activity/activity.info}} file (that conforms to the same spec) for activities. All sweets for Glucose components are located in the http://git.sugarlabs.org/sdk project.
 +
 +
Once checked out, these sources might be launched using {{Code|<nowiki>http://</nowiki>sweets.sugarlabs.org/''sweet-value-from-sweets.recipe''}} or just mentioning a sweet value:
 +
 +
sweets ''sweet''
 +
 +
For glucose projects, you can find ready-to-use and always-rebased-to-upstream projects in the [http://git.sugarlabs.org/sdk SDK] http://git.sugarlabs.org project. For now, there are two branches: {{Code|master}} for recent trunk, and {{Code|master-0.88}} for 0.88 code based on Dextrose-2 patches.
 +
 +
Checked-out projects will be built according to the {{Code|[Build]}} section commands in the {{Code|sweets.recipe}} files. In general, for autotools-based projects, there is no further need for the {{Code|sweets}} command; just run {{Code|make install}} to build current sources and install  them to the directory that was specified by {{Code|sweets}} in the configure stage. For glucose projects, there is no need even in calling the {{Code|make}} command (python code will be reused from its original location, see {{Code|binding}} options in [[Platform Team/Recipe Specification|sweets.recipe]] files), just change the code and restart sugar.
 +
  
 
== Writing recipe files ==
 
== Writing recipe files ==

Revision as of 13:10, 30 September 2011

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 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 sweet project level depends on the recipe file. For activities, 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 section to know about possible usage scenarios.

Recipe file is an ini format configuration file that might consist of several sections:

These files need to be placed to 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 that case, it is not different to .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 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=69624"