Platform Team/Guide/Sweets Usage

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).
  • Download and launch our self-extracted installer. Note, sweets is not intended to be installed from root user, use your current system user all time.
  • Installer will add ~/.local/bin directory to the PATH. So, re-login from an X session to take into account the new PATH.

Template:Admon/warning

Clone the sources

To checkout sugar project sources:

sweets --refresh --deep clone sugar

Where --deep says sweets process all dependencies.

Each project will be placed into the default ~/sweets directory. These are regular sources clones with one exception, each project contains a sweets.recipe spec file. Projects might be cloned in the regular way; 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

To see the progress of your sweet command

sweets -v sugar:emulator

To see 0install logs

sweets -vvv sugar:emulator

During the first launch, sources will be built. To rebuild them at any time:

sweets -ff make sweet

To see build output, use -v command line argument (adding more -v arguments will increase verbose level).

Run sweets from X session

Place sweets invocation into your ~/.xsession file:

PATH=$HOME/.local/bin:$PATH
sweets 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

Development workflow with sweets

Cloned 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.

Upgrade

To use testing versions, enable "Help test new versions" checkbox on:

0launch -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 sweets command.

Current limitations

  • Glucose needs to be patched, thus these are gitorious forks.
  • Packages cannot be built from sources without cloning.
  • 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