5,705
edits
Changes
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]].+ − == Run Sweets from sources ==+ − 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}}.+ − * 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):+ + + Line 13:
Line 15: − == Development workflow with sweets ==+ − 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:+ − sweets checkout [''path-to-sources'']+ − <!-- is the path-to-sources argument optional? If not, no square brackets. -->+ − 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.+ Line 37:
Line 47: + + + + + + + + + + +
Platform Team/Guide/Sweets Packaging (view source)
Revision as of 14:10, 30 September 2011
, 14:10, 30 September 2011no edit summary
== 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 [[Platform_Team/Sweets|introduction page]] and [[Platform_Team/Guide/Sweets_Usage|Usage guide]]. To understand conceptual ideas, read the [[Platform_Team/Sweets/Glossary|Glossary]].
== 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
./sweets upgrade
./sweets upgrade
The command {{Code|./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 {{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.
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.
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.
== 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:
* 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.
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 ==
<!--
<!--
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 ==