Changes

* The method to share software projects should to be as convenient as possible.

* The method to share software projects should to be as convenient as possible.

* It is important to stimulate users into becoming doers, to modify existing activities, and to share the results of their experiments with other people, i.e., a distribution method should handle different variants of the same project.

* It is important to stimulate users into becoming doers, to modify existing activities, and to share the results of their experiments with other people, i.e., a distribution method should handle different variants of the same project.

* This distribution method is not intended to be the only one.

* This distribution method is not intended to be the only one and more targeted to direct distribution, from software creators to software users.

The purpose is to create a new distribution method instead of reusing:

The purpose is to create a new distribution method instead of reusing:

* ''.xo bundles''

# ''.xo bundles''

** Work smoothly only for pure python activities, and only if all (and the same) dependencies are installed on all systems. They stop working smoothly if activities use non-standard dependencies or contain binaries.

#* Work smoothly only for pure python activities, and only if all (and the same) dependencies are installed on all systems. They stop working smoothly if activities use non-standard dependencies or contain binaries.

** Users need to manually handle the variety of activity versions, e.g., sort out all local bundles or directories in {{Code|~/Activities}}.

#* Users need to manually handle the variety of activity versions, e.g., sort out all local bundles or directories in {{Code|~/Activities}}.

* ''native packages''

# ''native packages''

** Not the shortest way between developers and users.

#* Not the shortest way between developers and users.

** In most cases, they don't support multiple versions of the same project.

#* In most cases, they don't support multiple versions of the same project.

** They don't work at all for sharing results of experiments.

#* They don't work at all for sharing results of experiments.

At the same time, existing distribution methods are reused in Sweets:

At the same time, existing distribution methods are reused in Sweets:

* ''.xo bundles'' is a subset of the Sweets workflow

# ''.xo bundles'' is a subset of the Sweets workflow

** It is possible to bundle an entire directory as a sweet project to use it as a regular .xo file.

#* It is possible to bundle an entire directory as a sweet project to use it as a regular .xo file.

* ''native packages''

# ''native packages''

** Sweets is not intended to create one more GNU/Linux distribution. It distributes only projects that people create within the Sugar community; all other software will be reused from native packages.

#* Sweets is not intended to create one more GNU/Linux distribution. It distributes only projects that people create within the Sugar community; all other software, i.e., dependencies, will be reused from native packages.

#* It is possible, when there is a need, to automatically package sweets into native packages. See [[Platform_Team/Sweets_Distribution|Sweets Distribution]] for example.

== Start from ==

== Zero Install basis ==

Start from these pages:

The Sweets is entirely based on Zero Install. It might be treated as a tools and infrastructure wrapper around Zero Install. See Zero Install's home page, http://0install.net/, for detailed information.

* [[Platform_Team/Guide/Sweets_Usage|Sweets Usage]] guide.

 

 

 

 

* The [[Platform_Team/Guide/Sweets_Usage|Sweets Usage]] guide to know how to launch software using the Sweets.

 

 

 

 

* Recipe files [[Platform_Team/Recipe_Specification|specification]].