Platform Team/Package Management System

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 targeting to support direct doer-to-user interaction model i.e. without transmissive chain of doer-to-distributor-to-user (but Zero Sugar could be still useful for distributors since it unifies deployment workflow).

Benefits

How Zero Sugar could be useful depending upon your point of view:

Users

Users can run sugar in various environments (machine architectures, GNU/Linux distributions etc.) and since sugar also stimulates users to be doers, there could be tons of handmade software in the field (mostly duplicates and reinvented wheels but it is nature of sugar i.e. process does matter). It is becoming critical to provide easy and robust launching scheme for all these pieces of code without writing long HOWTOs somewhere on wiki like "Please, if you are on Ubuntu, install these packages before starting my activity...".

Relying only on particular distributor i.e. using activities only from distributor's channel makes sugar not so useful. Zero Sugar provides direct deployment method between author of code and its users in as convenient as possible way.

Doers

Author of code all time is interested in supporting as big as possible users audience. And since people can use sugar in different environments, it is critical to provide instrument which allows to run activity on all sugar platforms. In case of python (only python, not even arbitrary scripting language since python is a part of Sugar Platform) based activities, existed practice with just zipping activity to .xo files works pretty well. But it is a problem with non-python activities or activities that have dependencies not included to Sugar Platform.

Zero Sugar tries to solve possible issues that prevent activity launching in heterogeneous Sugar environment.

Also, if you have some idea in mind, you can start pushing it through the Sucrose release queue to get it into an upcoming (maybe not the nearest) release. However, since the release process is binary—either your feature is included or not—Zero Sugar offers more flexibility. For example:

• some features are of arguable general benefit; Zero Sugar would allow interested end users to efficiently test (and even deploy) such features;
• some feature are only stable in limited environments; Zero Sugar would allow deployment in limited environments without the risk of destabilizing the rest of Sugar.

Distributors

The Sugar Platform cannot grow endlessly, e.g., installing sugar from packages should not fetch half of all available packages including several UI toolkits, several programming languages, etc., so components like Qt or Ruby are (at least at present) out of the Sugar Platform list. But with Zero Sugar, activities can still use such dependencies by installing them from native packaging systems on demand and without bundling binaries.

How it works at glance

Instruments and services that are used within Zero Sugar:

• 0sugar main tool, everything happen via 0sugar command
• 0install decentralized deployment infrastructure
• OBS openSUSE Build Service, build farms and repository of native packages for GNU/Linux distributions OBS supports
• PackageKit to install software from native packaging systems
• Sugar Labs's resources to host various files

Departing point is a spec file which is used by 0sugar command to accomplish two major tasks:

• how to build application and its dependencies
• how to deploy application and its dependencies

Building might happen:

• building is not required for scripting languages
• on developer's box, to deploy to environments similar to developer's
• on OBS, to build on GNU/Linux distributions OBS supports

Deploying will happen:

• via 0install infrastructure:
  • analogs of application and its dependencies could be installed from native packaging system if PackageKit is installed
  • if application was built in developer's environment, downloading from http://download.sugarlabs.org/
  • if application was built on OBS, downloading from OBS repositories
• via native packages, only if build happened on OBS; users need to follow regular, for their distributions, workflow to attach external OBS repository

Documentation

Start your exploration from:

• Activity Developers Guide to get instructions how to use the already created Zero Sugar packages in activities
• Service Developers Guide for how to create Zero Sugar package

See Scalable development model to learn more about the initial intentions for Zero Sugar.