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

Revision as of 20:06, 15 March 2011

This guide describes how to use Sugar Labs' SDK for developing core modules.

Requirements

Install PackageKit and PackageKit authentication agent from native packages. On Debian-based systems, these packages are packagekit and packagekit-gnome (for Gnome Desktop Environment). For Fedora, PackageKit and gnome-packagekit.

PackageKit authentication agent should be launched to let the sweets command install dependencies. Usually it is started after being logged into a Desktop Environment session (it isn't for Sugar session).

Clone sweets sources and install it (after the first run you need to relogin to take into account new PATH value, then just run sweets command):

git clone --recursive git://git.sugarlabs.org/sdk/sweets.git
sweets/sweets upgrade

Launch sugar

To launch sugar session:

sweets sdk/sugar

or to run from Xephyr:

sweets sdk/sugar:emulator

Development workflow with sweets

During the first launch, sources will be auto-built and kept in internal storage. To make sweets useful for the code you are developing, register sources (sweets.recipe should exist in sources):

sweets checkout [path-to-sources]

After that, sources might be launched via sweets by mentioning its sweet value.

sweets your-sweet

Registered projects will be built according to [Build] section commands in recipe files. In general, for autotools-based projects, there is no further need for the sweets command, just run make install to build current sources and copy them to the directory that was specified by sweets in the configure stage.

For glucose projects, there is no need even in calling the make command, python code will be reused from its original place (see binding options in sweets.recipe files), change the code and restart sugar.

For activities, follow regular activity developing procedure - clone them to ~/Activities directory and run from sugar shell.

Run sweets from X session

Place sweets invocation into your ~/.xsession file:

PATH=$HOME/.local/bin:$PATH
sweets sdk/sugar

and create a /usr/share/xsessions/sweets.desktop desktop file:

[Desktop Entry]
Encoding=UTF-8
Name=Sweets
GenericName=Sweets
Exec=/etc/X11/Xsession
Type=Application

Current limitations

For now, sweets knowns only about glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE, and Gentoo.
Activities can't reuse sweets benefits.

Feedback

Submit your bug report.
Ask your question on IRC channels, #sugar (not logged) or #sugar-newbies (logged).

@@ Line 4: / Line 4: @@
 * Install PackageKit and PackageKit authentication agent from native packages. On Debian-based systems, these packages are {{Code|packagekit}} and {{Code|packagekit-gnome}} (for Gnome Desktop Environment). For Fedora, {{code|PackageKit}} and {{Code|gnome-packagekit}}.
 * PackageKit authentication agent should be launched to let the {{Code|sweets}} command install dependencies. Usually it is started after being logged into a Desktop Environment session (it isn't for Sugar session).
-* Download and launch our [http://download.sugarlabs.org/packages/0sugar/sweets.sh self-extracted installer]. Note, sweets is not intended to be installed from {{Code|root}} user, use your current system user all time.
-* Installer will add {{Code|~/.local/bin}} directory to the {{Code|PATH}}. So, re-login from an X session to take into account the new {{Code|PATH}}.
-{{Admon/warning|In the current implementation, installation progress is not reported while installing packages via PackageKit.|When there are many dependencies to install for the first time, it might take some time to install them.<br>To see installation progress use the {{Code|pkmon}} command.}}
+* Clone sweets sources and install it (after the first run you need to relogin to take into account new PATH value, then just run {{Code|sweets}} command):
+ git clone --recursive git://git.sugarlabs.org/sdk/sweets.git
+ sweets/sweets upgrade
+== Launch sugar ==
+To launch sugar session:
+ sweets sdk/sugar
+or to run from Xephyr:
+ sweets sdk/sugar:emulator
+== Development workflow with sweets ==
-== Clone the sources ==
-To checkout sugar project sources:
- sweets --refresh --deep clone sugar
-Where {{Code|--deep}} says {{Code|sweets}} process all dependencies.
-Each project will be placed into the default {{Code|~/sweets}} directory. These are regular sources clones with one exception, each project contains a [[Platform Team/Recipe Specification|sweets.recipe]] spec file.
-Projects might be cloned in the regular way; {{Code|sweets clone}} is just a convenient method since some of the projects are gitorious forks.
-== Launch sugar ==
-To launch sugar session:
- sweets sugar
-or to run from Xephyr:
- sweets sugar:emulator
+During the first launch, sources will be auto-built and kept in internal storage. To make sweets useful for the code you are developing, register sources ([[Platform Team/Recipe Specification|sweets.recipe]] should exist in sources):
-To see the progress of your sweet command
+ sweets checkout [''path-to-sources'']
- sweets -v sugar:emulator
+After that, sources might be launched via sweets by mentioning its ''sweet'' value.
-To see 0install logs
+  sweets ''your-sweet''
-  sweets -vvv sugar:emulator
-During the first launch, sources will be built. To rebuild them at any time:
+Registered projects will be built according to {{Code|[Build]}} section commands in 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 copy them to the directory that was specified by {{Code|sweets}} in the configure stage.
- sweets -ff make ''sweet''
+For glucose projects, there is no need even in calling the {{Code|make}} command, python code will be reused from its original place (see {{Code|binding}} options in [[Platform Team/Recipe Specification|sweets.recipe]] files), change the code and restart sugar.
-To see build output, use {{Code|-v}} command line argument (adding more {{Code|-v}} arguments will increase verbose level).
+For activities, follow regular activity developing procedure - clone them to {{Code|~/Activities}} directory and run from sugar shell.
 === Run sweets from X session ===
@@ Line 50: / Line 52: @@
   PATH=$HOME/.local/bin:$PATH
-  sweets sugar
+  sweets sdk/sugar
 and create a {{Code|/usr/share/xsessions/sweets.desktop}} desktop file:
@@ Line 60: / Line 62: @@
   Exec=/etc/X11/Xsession
   Type=Application
-== Development workflow with sweets ==
-Cloned projects will be built according to {{Code|[Build]}} section commands in 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 copy 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 place (see {{Code|binding}} options in [[Platform Team/Recipe Specification|sweets.recipe]] files), change the code and restart sugar.
-For activities, follow regular activity developing procedure - clone them to {{Code|~/Activities}} directory and run from sugar shell.
-== Upgrade ==
-To use testing versions, enable "Help test new versions" checkbox on:
-launch -g
-To upgrade sweets itself to the recent version:
- sweets -R upgrade
-== Run sweets from sources ==
- git clone --recursive git://git.sugarlabs.org/sdk/sweets.git
- sweets/sweets upgrade
-After the first run, you need to relogin to take into account new PATH value. Then, just run {{Code|sweets}} command.
 == Current limitations ==
-* Glucose needs to be patched, thus these are gitorious forks.
-* Packages cannot be built from sources without cloning.
 * For now, {{Code|sweets}} knowns only about glucose dependencies to install them from native packages in Debian, Ubuntu, Fedora, Mandriva, openSUSE, and Gentoo.
 * Activities can't reuse sweets benefits.