5,705
edits
Changes
Jump to navigation
Jump to search
Platform Team/Infrastructure (view source)
Revision as of 22:51, 25 November 2010
, 22:51, 25 November 2010Created page with "An overview of Sugar doers environment implementation. === Command line interface === Only {{Code|sweets}} command is needed to interact ..."
An overview of Sugar doers environment implementation.
=== [[Platform Team/Guide/sweets command|Command line interface]] ===
Only {{Code|sweets}} command is needed to interact with doers environment. See walk-through [[Platform_Team/Doers_environment#Start_from|tutorials]] for various use cases.
=== Software projects, sweets ===
Software projects (not only Sugar related) are named ''sweets'' within doers environment and might be one of several types:
* aliases to native GNU/Linux packages that map the same sweet name to appropriate package name for particular GNU/Linux distribution (further, aliases),
* recipe based, i.e., native for sugar environment, projects (further, sweets).
==== [[Platform Team/Recipe Specification|Recipes]] ====
This is the departing point for both, users and doers, environments for particular sweet project. It is intended to accomplish the major task - how to prepare the code to launch.
Sweets contain recipe file in sources directory. Recipes are improved versions of {{Code|activity.info}} files with the difference that recipes fully describe the sweet (i.e., like GNU/Linux distribution spec files do) and intended not only for activities.
Recipes contain various metadata about the sweet, including important ones like version, dependencies and ''sweet_id''. The value of ''sweet_id'' is just a short (not unique) name which is being used in various sweet [[#Identifiers|identifiers]].
==== Identifiers and implementations ====
All sweets are identified by Web URLs:
* urls for unique identification:
<nowiki>http</nowiki>://sweets.''bazaar-hostname''/''user-account''/''sweet_id''
* urls to collect all implementations for the same {{Code|sweet_id}}:
<nowiki>http</nowiki>://sweets.''bazaar-hostname''/''sweet_id''
Where:
* ''bazaar-hostname'', [[#Bazaar|Bazaar]] instance which is being used to host projects
* ''user-account'', account name of the developer on [[#Bazaar|Bazaar]]
* ''sweet_id'', sweet identifier from the project recipe
The same unique identifier might be associated with several sweet implementations from the same doer. Implementation is just a copy of the sweet in ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen in running environment basing on Operating System, GNU/Linux distribution, or user preferences (like running only stable versions).
The reason to have second type of sweet identifiers is collecting sweet implementations from several doers. For example, doer might tweak existed project and share it, other people will be aware of existence of another sweet implementations. The process of choosing the proper implementation to run, will be extended by additional options like choosing implementations only from particular doer.
==== Development implementations ====
Ready to use sweets implementations, i.e., locally available, might be in two states:
* read-only implementations that might be only used,
* under development implementations that might be changed at anytime.
In other words, development implementations are just checked out sweets sources placed to one of default directories, by default {{Code|~/sweets}} and {{Code|~/Activities}}.
Development implementations have the highest run priority but it might be changed by user at any time since these are regular implementations.
Development implementations is the right way for [http://en.wikipedia.org/wiki/Sneakernet sneakernet] sharing of activities, just bundling sweet directory and extracting it on another machine is needed.
=== Sweets tracker ===
Sweets tracker is a DBus service that is being used by {{Code|sweets}} command and Sugar Shell to run sweets and handle other high-level sweets related procedures.
The reasons to have DBus service are:
* need to monitor development implementations to not scan directories every time,
* cache 0install internal procedures to speed up launch process,
* background updates,
* support [http://0install.net/0mirror.html mirroring] of 0install implementations to share already downloaded files within local network to decrease internet traffic.
=== [[Platform_Team/Bazaar|Bazaar]] ===
Bazaar is a patched version of [https://build.opensuse.org/ OBS]. It handles all server-client share related procedures, like hosting sweet sources and implementation. For binary based sweets, Bazaar is a build farm as well.
In many cases Bazaar will be used implicitly:
* uploading new version will be called from {{Code|sweets commit}} command,
* launch will happen just by mentioning sweet url.
The only thing is needed, being registered on Bazaar. For default http://bazaar.sugarlabs.org instance, being registered in [https://cas.sugarlabs.org/ Sugar Labs Central Login] system.
=== [[Activity Library]] ===
In doers environment, Activity Library will be a catalog of sweets. It might be treated as a frontend of Sugar development, when [[#Bazaar|Bazaar]] is a backend and an analog of the current Developer Hub on Activity Library.
The only sweet URL is needed to add new Activity Library entity, the rest will be fetched from the sweet. Also [[#Bazaar|Bazaar]] might automatically publish information of newly created sweet implementations.
=== [[Platform Team/Guide/sweets command|Command line interface]] ===
Only {{Code|sweets}} command is needed to interact with doers environment. See walk-through [[Platform_Team/Doers_environment#Start_from|tutorials]] for various use cases.
=== Software projects, sweets ===
Software projects (not only Sugar related) are named ''sweets'' within doers environment and might be one of several types:
* aliases to native GNU/Linux packages that map the same sweet name to appropriate package name for particular GNU/Linux distribution (further, aliases),
* recipe based, i.e., native for sugar environment, projects (further, sweets).
==== [[Platform Team/Recipe Specification|Recipes]] ====
This is the departing point for both, users and doers, environments for particular sweet project. It is intended to accomplish the major task - how to prepare the code to launch.
Sweets contain recipe file in sources directory. Recipes are improved versions of {{Code|activity.info}} files with the difference that recipes fully describe the sweet (i.e., like GNU/Linux distribution spec files do) and intended not only for activities.
Recipes contain various metadata about the sweet, including important ones like version, dependencies and ''sweet_id''. The value of ''sweet_id'' is just a short (not unique) name which is being used in various sweet [[#Identifiers|identifiers]].
==== Identifiers and implementations ====
All sweets are identified by Web URLs:
* urls for unique identification:
<nowiki>http</nowiki>://sweets.''bazaar-hostname''/''user-account''/''sweet_id''
* urls to collect all implementations for the same {{Code|sweet_id}}:
<nowiki>http</nowiki>://sweets.''bazaar-hostname''/''sweet_id''
Where:
* ''bazaar-hostname'', [[#Bazaar|Bazaar]] instance which is being used to host projects
* ''user-account'', account name of the developer on [[#Bazaar|Bazaar]]
* ''sweet_id'', sweet identifier from the project recipe
The same unique identifier might be associated with several sweet implementations from the same doer. Implementation is just a copy of the sweet in ready-to-use state, e.g., several versions of the sweet, several binary implementations of the same sweet version built against several environments. Only one implementation will be chosen in running environment basing on Operating System, GNU/Linux distribution, or user preferences (like running only stable versions).
The reason to have second type of sweet identifiers is collecting sweet implementations from several doers. For example, doer might tweak existed project and share it, other people will be aware of existence of another sweet implementations. The process of choosing the proper implementation to run, will be extended by additional options like choosing implementations only from particular doer.
==== Development implementations ====
Ready to use sweets implementations, i.e., locally available, might be in two states:
* read-only implementations that might be only used,
* under development implementations that might be changed at anytime.
In other words, development implementations are just checked out sweets sources placed to one of default directories, by default {{Code|~/sweets}} and {{Code|~/Activities}}.
Development implementations have the highest run priority but it might be changed by user at any time since these are regular implementations.
Development implementations is the right way for [http://en.wikipedia.org/wiki/Sneakernet sneakernet] sharing of activities, just bundling sweet directory and extracting it on another machine is needed.
=== Sweets tracker ===
Sweets tracker is a DBus service that is being used by {{Code|sweets}} command and Sugar Shell to run sweets and handle other high-level sweets related procedures.
The reasons to have DBus service are:
* need to monitor development implementations to not scan directories every time,
* cache 0install internal procedures to speed up launch process,
* background updates,
* support [http://0install.net/0mirror.html mirroring] of 0install implementations to share already downloaded files within local network to decrease internet traffic.
=== [[Platform_Team/Bazaar|Bazaar]] ===
Bazaar is a patched version of [https://build.opensuse.org/ OBS]. It handles all server-client share related procedures, like hosting sweet sources and implementation. For binary based sweets, Bazaar is a build farm as well.
In many cases Bazaar will be used implicitly:
* uploading new version will be called from {{Code|sweets commit}} command,
* launch will happen just by mentioning sweet url.
The only thing is needed, being registered on Bazaar. For default http://bazaar.sugarlabs.org instance, being registered in [https://cas.sugarlabs.org/ Sugar Labs Central Login] system.
=== [[Activity Library]] ===
In doers environment, Activity Library will be a catalog of sweets. It might be treated as a frontend of Sugar development, when [[#Bazaar|Bazaar]] is a backend and an analog of the current Developer Hub on Activity Library.
The only sweet URL is needed to add new Activity Library entity, the rest will be fetched from the sweet. Also [[#Bazaar|Bazaar]] might automatically publish information of newly created sweet implementations.