Platform Team/Guide/Sweets Usage

This guide describes how to use Sugar Labs' Doers environment 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.

Clone the sources

To checkout sugar project sources:

sweets --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

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

sweets -ff make sweet

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 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 git://git.sugarlabs.org/0sugar/sweets.git <install-path>
echo 'PATH=~/.local/bin:$PATH' >> ~/.bashrc
mkdir -p ~/.local/bin
ln -fs <full-install-path>/0run ~/.local/bin/0run
ln -fs 0run ~/.local/bin/sweets
ln -fs 0run ~/.local/bin/0launch
cd <install-path>
git submodule init
git submodule update

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.