Platform Team/Guide/Sweets Usage: Difference between revisions

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:~~

~~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 {{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.

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