Difference between revisions of "Platform Team/Package Management System"
(→Users) |
|||
Line 14: | Line 14: | ||
=== Users === | === 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..." | + | 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...". |
− | Zero Sugar provides direct deployment method between author of code and its users in as convenient as possible way. | + | 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 === | === Doers === |
Revision as of 10:03, 26 June 2010
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 to install:
- software that were built by developer, downloading from http://download.sugarlabs.org/
- packages will be downloaded from OBS repositories if build happened on OBS
- 0install might install application and its dependencies from native packages if PackageKit is installed
- 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.