Changes

== Zero Sugar Distribution ==

== Zero Sugar Distribution ==

Zero Sugar provides a method that is transparent for users and convenient for doers to deploy software across varying platforms as well as across Sugar releases. Zero Sugar is mainly targeted to support a direct, doer-to-user interaction model, i.e., shortcut the chain of transfer of doer-to-distributor-to-user (still, Zero Sugar could be [[#Distributors|beneficial]] for distributors, since it unifies the deployment workflow).

Zero Sugar provides a method that is transparent for users and convenient for doers to deploy software across varying platforms as well as across Sugar releases. Zero Sugar is mainly targeted to support a direct, doer-to-user interaction model, i.e., shortcut the chain of transfer of doer-to-distributor-to-user (still, Zero Sugar could be [[#Distributors|beneficial]] for distributors, since it unifies the deployment workflow).

== Benefits ==

== Benefits ==

* [[Activity Team/Zero Sugar/0sugar|0sugar]], the main tool, everything happens via the {{Code|0sugar}} command.

* [[Activity Team/Zero Sugar/0sugar|0sugar]], the main tool, everything happens via the {{Code|0sugar}} command.

* [http://0install.net/ 0install] decentralized deployment infrastructure.

* [http://0install.net/ 0install] decentralized deployment infrastructure.

* [http://build.opensuse.org/ OBS], openSUSE Build Service, build farms and repository of native packages for the GNU/Linux distributions and architectures that OBS [http://wiki.opensuse.org/openSUSE:Build_Service_supported_build_targets supports].

* [http://build.opensuse.org/ OBS], openSUSE Build Service, that is patched to accomplish Zero Sugar needs. OBS will be hosted on SugarLabs servers and accessible from http://refinery.sugarlabs.org site. It will be a central place for all files related procedures like hosting various files, building binary-based activities, provide GNU/Linux distribution repositories for centralized Sugar distributions.

* [http://www.packagekit.org/ PackageKit] to install software from native packaging systems.

* [http://www.packagekit.org/ PackageKit] to install software from native packaging systems.

=== Identification ===

=== Identification ===

** more efficient disk-storage usage e.g remove less frequently used activities to save space for new ones.

** more efficient disk-storage usage e.g remove less frequently used activities to save space for new ones.

=== Spec file ===

=== Recipe file ===

The process departing point is a [[Activity Team/Zero Sugar/0sugar.info Specification|spec file]] which is used within Zero Sugar to accomplish two major tasks:

The process departing point is a [[Activity Team/Zero Sugar/0sugar.info Specification|recipe file]] which is used within Zero Sugar to accomplish the major task - how to prepare the code to launch.

The Zero Sugar recipe file is an all-sufficient entity. With only the file and {{Code|0sugar}} tool, it is possible to prepare the code necessary to launch in various environments like the major rpm/deb-based GNU/Linux distributions or just launch locally.

 

The Zero Sugar spec file is an all-sufficient entity. With only the spec file and tools like {{Code|0sugar}} and {{Code|0distro}}, it is possible to prepare the code necessary to launch in various environments like the major rpm/deb-based GNU/Linux distributions or just launch locally.

=== Prepare the code ===

=== Prepare the code ===

The preparation step can be trivial, unless the code requires a building stage. Building might occur:

The preparation step can be trivial, unless the code requires a building stage. Building might occur:

* on the developer's workstation, to deploy to environments similar to the developer's,

* on the developer's workstation, to deploy to environments similar to the developer's,

* on OBS, to build for the GNU/Linux distributions that OBS supports, or

* on http://refinery.sugarlabs.org, to build for the GNU/Linux distributions that are supported by Refinery Team, or

* building might happen on the user's side, if other methods don't work.

* building might happen on the user's side, if other methods don't work.

Sharing step might be:

Sharing step might be:

* ''local'', if code needs to be run only in the doer's environment.<br>Zero Sugar spec file will be handled as a regular {{Code|activity.info}} file.

* ''local'', if code needs to be run only in the doer's environment.<br>Zero Sugar recipe file will be handled as a regular {{Code|activity.info}} file.

* ''peer-to-peer'', direct sharing between doer and users.

* ''peer-to-peer'', direct sharing between doer and users.

** Code can be launched if on-line users in the Neighborhood View have a copy of shared code, i.e., the doer only needs to be on-line to let other people launch his code.

** Code can be launched if on-line users in the Neighborhood View have a copy of shared code, i.e., the doer only needs to be on-line to let other people launch his code.

* ''client-server'', doer needs to upload code to the server, and users will download it.<br>The particular method might be different:

* ''client-server'', doer needs to upload code to the server, and users will download it.<br>The particular method might be different:

** via the 0install infrastructure,

** via the 0install infrastructure,

** via OBS repositories with native packages,

** via http://refinery.sugarlabs.org repositories with native packages,

** by uploading bundles to servers like ASLO.

** by uploading bundles to servers like ASLO.

* ''distributor'', most likely similar to ''client-server'', but different from the doer's point of view, since only the distributor is responsible for a particular distribution method.

* ''distributor'', most likely similar to ''client-server'', but different from the doer's point of view, since only the distributor is responsible for a particular distribution method.

The regular workflow within Zero Sugar, in the case of coding a Python-based activity, will look like the following:

The regular workflow within Zero Sugar, in the case of coding a Python-based activity, will look like the following:

* Create activity [[Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity|spec file]].

* Create activity [[Activity_Team/Zero_Sugar/0sugar.info_Specification#Python_activity|recipe file]].

* Code the activity.

* Code the activity.

* Try current code in Sugar just by selecting an icon in the activities list.

* Try current code in Sugar just by selecting an icon in the activities list.

* When a milestone is achieved, call:

* When a milestone is achieved, call {{Code|0sugar dist commit}} to create sources tarballs and send them to http://refinery.sugarlabs.org.

** {{Code|0sugar dist}} to create sources tarball

* After that, activity will be accessible for direct usage (via 0install) and for distributors that are eager to deploy it (via native packages).

** {{Code|0sugar commit}} to let Sugar know that the activity can be shared in peer-to-peer mode between on-line users

* If doer wants to support server-client sharing model for a broad audience of users:

** choose the server to host 0install files (it could be [[Sysadmin/Shell_account_request|sunjammer.sugarlabs.org]] or any other server to rsync files to),

** call, {{Code|0sugar publish}} to publish 0install files

* options for distributors:

** If it is an OBS-based distribution, there is no need for any packaging-related work at all, just link/branch the activity to your distribution project.

** Use the activity spec file and {{Code|0distro}} command to build native packages on non-OBS build farms. Most likely, the resulting packages will not conform to all the requirements for inclusion in an official repository, but this feature could still be useful when strong packaging rules are not required, e.g., in various Sugar/edu derivates like Trisquel-edu, SoaS or USR.

** Having a link to sources tarball on the page, package is identified by, and information about dependencies from the spec file, create a regular package for any particular GNU/Linux distribution.

== Documentation ==

== Documentation ==