Platform Team/Guide/Sweets Packaging - Revision history

Alsroot at 05:30, 23 September 2012

2012-09-23T05:30:03Z

← Older revision		Revision as of 01:30, 23 September 2012
Line 53:		Line 53:

	* suffixes for final ''interface''s, e.g., {{Code\|http://sweets.sugarlabs.org/''<value>''}},		* suffixes for final ''interface''s, e.g., {{Code\|http://sweets.sugarlabs.org/''<value>''}},
	* the name of project/package on [[Platform_Team/~~Open_Build_System~~\|OBS]] that will be used to host released sweet.		* the name of project/package on [[Platform_Team/Open_Build_Service\|OBS]] that will be used to host released sweet.

	In the 2nd case, the last slash separated part is a package, and the rest is a project, e.g., for ''sdk/sugar'', ''sdk'' is a project and ''sugar'' is a package in the ''sdk'' project.		In the 2nd case, the last slash separated part is a package, and the rest is a project, e.g., for ''sdk/sugar'', ''sdk'' is a project and ''sugar'' is a package in the ''sdk'' project.
	It is possible to have interface values without slashes, in that case, project and package names are the same.		It is possible to have interface values without slashes, in that case, project and package names are the same.

	In the [[Platform_Team/~~Open_Build_System~~\|OBS]], there is a special project named ''base''. This project contains sweets that all time will be represented only by native packages. In other words, if you need to make sure that your sweet needs to depend only on native packages, use dependencies from the ''base'' project.		In the [[Platform_Team/Open_Build_Service\|OBS]], there is a special project named ''base''. This project contains sweets that all time will be represented only by native packages. In other words, if you need to make sure that your sweet needs to depend only on native packages, use dependencies from the ''base'' project.

	The ''base'' project is also useful for [[Platform_Team/Sweets/Glossary#Associated_interfaces\|associated]] interfaces set in ''associate'' recipe option. For example, if your sweet needs ''pygame=2'' dependency that is not yet widespread, create ''~user/pygame'' temporary sweet with ''2'' version only, and use ''~user/pygame'' as a dependency in your sweet. If ''base/pygame'' will be added as associated interface to the ''~user/pygame'', users that have ''>=2'' version in native packages will reuse them instead of ''~user/pygame'''s one.		The ''base'' project is also useful for [[Platform_Team/Sweets/Glossary#Associated_interfaces\|associated]] interfaces set in ''associate'' recipe option. For example, if your sweet needs ''pygame=2'' dependency that is not yet widespread, create ''~user/pygame'' temporary sweet with ''2'' version only, and use ''~user/pygame'' as a dependency in your sweet. If ''base/pygame'' will be added as associated interface to the ''~user/pygame'', users that have ''>=2'' version in native packages will reuse them instead of ''~user/pygame'''s one.
Line 181:		Line 181:
	== Releasing ==		== Releasing ==

	In Sweets, releasing means uploading a sources tarball with a release (though, that [[#Stability_status\|doesn't only mean]] stable versions) to the Sugar Labs [[Platform_Team/~~Open_Build_System~~\|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have a Sugar Labs [[Service/Account#Sugar_Labs_Central_Login\|account]]. A login with password will be required the first time or when your cookie is missing.		In Sweets, releasing means uploading a sources tarball with a release (though, that [[#Stability_status\|doesn't only mean]] stable versions) to the Sugar Labs [[Platform_Team/Open_Build_Service\|instance]] of the [http://openbuildservice.org/ Open Build Service] (OBS). Before releasing, make sure that you have a Sugar Labs [[Service/Account#Sugar_Labs_Central_Login\|account]]. A login with password will be required the first time or when your cookie is missing.

	Before releasing, make sure that your recipe conforms to the OBS [[Platform_Team/~~Open_Build_System~~/Policy\|Policy]]. While releasing, sweet sources will be uploaded to an OBS project/package according to the [[#Interfaces\|implement]] recipe option. If a particular project or package don't exist, they will be created (upon user's confirmation for project creation).		Before releasing, make sure that your recipe conforms to the OBS [[Platform_Team/Open_Build_Service/Policy\|Policy]]. While releasing, sweet sources will be uploaded to an OBS project/package according to the [[#Interfaces\|implement]] recipe option. If a particular project or package don't exist, they will be created (upon user's confirmation for project creation).

	To initiate releasing, enter from the sweet sources directory:		To initiate releasing, enter from the sweet sources directory:

FGrose: /* Launch activity */

2011-12-07T00:47:24Z

Launch activity

← Older revision		Revision as of 20:47, 6 December 2011
Line 246:		Line 246:
	=== Launch activity ===		=== Launch activity ===

	Before starting Sugar Shell, place your activity's sources directory to the {{Code\|~/Activities}}, or place there a symbolic link to activity sources. After running Sugar Shell, new activity will appear in the Home (if it's absent in the Favorites ~~View~~, switch to the List ~~View~~).		Before starting Sugar Shell, place your activity's sources directory under the {{Code\|~/Activities/}} directory, or place there a symbolic link to the activity sources. After running Sugar Shell, the new activity will appear in the Home view (if it's absent in the Favorites view, switch to the List view).

	== Good practices ==		== Good practices ==

Alsroot: /* Launch activity */

2011-12-06T23:57:18Z

Launch activity

← Older revision		Revision as of 19:57, 6 December 2011
Line 246:		Line 246:
	=== Launch activity ===		=== Launch activity ===

	Before starting Sugar Shell, place your activity's sources directory to {{Code\|~/Activities}}, or place there a symbolic link to activity sources. After running Sugar Shell, new activity will appear in Home (if it's absent in Favorites View, switch to List View).		Before starting Sugar Shell, place your activity's sources directory to the {{Code\|~/Activities}}, or place there a symbolic link to activity sources. After running Sugar Shell, new activity will appear in the Home (if it's absent in the Favorites View, switch to the List View).

	== Good practices ==		== Good practices ==

Alsroot: /* Developing activities */

2011-12-06T23:54:23Z

Developing activities

← Older revision		Revision as of 19:54, 6 December 2011
Line 215:		Line 215:
	and see its {{Code\|sweets.recipe}} files.		and see its {{Code\|sweets.recipe}} files.

	=== ~~Developing~~ activities ===		== Developing activities ==

			How Sweets might be useful while developing activities.

			=== Manage sources ===

	The traditional development related routine for activity sources is to run the {{Code\|setup.py}} script located in the root activity directory. With Sweets, these routines might be accomplished with the {{Code\|sweets}} command. Here is some background information:		The traditional development related routine for activity sources is to run the {{Code\|setup.py}} script located in the root activity directory. With Sweets, these routines might be accomplished with the {{Code\|sweets}} command. Here is some background information:
Line 239:		Line 243:

	sweets build [PATH]		sweets build [PATH]

			=== Launch activity ===

			Before starting Sugar Shell, place your activity's sources directory to {{Code\|~/Activities}}, or place there a symbolic link to activity sources. After running Sugar Shell, new activity will appear in Home (if it's absent in Favorites View, switch to List View).

	== Good practices ==		== Good practices ==

RafaelOrtiz: typo

2011-12-06T22:42:31Z

typo

← Older revision		Revision as of 18:42, 6 December 2011
Line 223:		Line 223:
	* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.		* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.

	Sweets support the following {{Code\|setup.pu}}'s commands:		Sweets support the following {{Code\|setup.py}}'s commands:

	* {{Code\|build}}, build generated files, e.g., {{Code\|locale/}} directory;		* {{Code\|build}}, build generated files, e.g., {{Code\|locale/}} directory;

FGrose: /* Developing activities */

2011-12-06T22:26:39Z

Developing activities

← Older revision		Revision as of 18:26, 6 December 2011
Line 230:		Line 230:
	* {{Code\|genpot}}, generate the gettext pot file.		* {{Code\|genpot}}, generate the gettext pot file.

	And ~~don~~'t support the following:		And doesn't support the following:

	* {{Code\|dev}} - seems to be a needlessly exaggerated function that creates a symbolic link in the {{Code\|~/Activities}} directory to activity sources. The same might be done using the {{Code\|ln -s}} command to avoid having derived functionality, or better, place sources directly in the {{Code\|~/Activities}} directory;		* {{Code\|dev}} - seems to be a needlessly exaggerated function that creates a symbolic link in the {{Code\|~/Activities}} directory to activity sources. The same might be done using the {{Code\|ln -s}} command to avoid having derived functionality, or better, place sources directly in the {{Code\|~/Activities}} directory;

FGrose at 22:25, 6 December 2011

2011-12-06T22:25:14Z

← Older revision		Revision as of 18:25, 6 December 2011
Line 217:		Line 217:
	=== Developing activities ===		=== Developing activities ===

	The ~~regular way for~~ development related ~~routines regarding~~ activity sources is ~~runing~~ {{Code\|setup.py}} script located in the root activity directory. With Sweets, ~~all~~ these routines might be ~~used~~ with {{Code\|sweets}} command. ~~The reasons are~~:		The traditional development related routine for activity sources is to run the {{Code\|setup.py}} script located in the root activity directory. With Sweets, these routines might be accomplished with the {{Code\|sweets}} command. Here is some background information:

	* ~~The~~ downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (to have all libraries that {{Code\|setup.py}} ~~injected~~);		* A downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (in order to have all the libraries that {{Code\|setup.py}} injects);
	* Sweets is designed to support multiple software versions at the same time~~, it is not useful~~ to login to different Sugar ~~session~~ for creating~~, e.g.,~~ source tarballs~~; In other words~~, ~~having standalone utility~~ makes more sense;		* Sweets is designed to support multiple software versions at the same time. So to avoid having to login to different Sugar sessions for creating source tarballs, for example, it makes more sense to have a standalone utility;
	* {{Code\|sweets}} command already contains development related functionality, it is useful to keep all development related functions in one utility.		* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.

	Sweets support the following {{Code\|setup.pu}}'s commands:		Sweets support the following {{Code\|setup.pu}}'s commands:
Line 232:		Line 232:
	And don't support the following:		And don't support the following:

	* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources~~, the~~ same might be done using {{Code\|ln -s}} command to avoid having derived functionality, or better, ~~places source exactly to~~ {{Code\|~/Activities}} directory;		* {{Code\|dev}} - seems to be a needlessly exaggerated function that creates a symbolic link in the {{Code\|~/Activities}} directory to activity sources. The same might be done using the {{Code\|ln -s}} command to avoid having derived functionality, or better, place sources directly in the {{Code\|~/Activities}} directory;
	* {{Code\|fix_manifest}}, function ~~create~~ {{Code\|MANIFEST}} file~~, not~~ having this file is not a ~~fail~~ and Sweets is designed to have include/exclude rules in recipe files instead;		* {{Code\|fix_manifest}} - function creates {{Code\|MANIFEST}} file. Not having this file is not a failure, and Sweets is designed to have include/exclude rules in recipe files instead;
	* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during ~~the~~ regular behaviour.		* {{Code\|install}} - function installs the activity to the root system. Sweets avoid, by design, any global changes during its regular behaviour.

	As regular {{Code\|sweets}}'s commands, these ~~command~~ need to be executed ~~being in~~ activity directory (in any of its sub-directories, not ~~only~~ in the root), or path to activity sources might be specified after command name, e.g.:		As regular {{Code\|sweets}}'s commands, these commands need to be executed from the activity directory (or in any of its sub-directories, not just in the root), or the path to activity sources might be specified after the command name, e.g.:

	sweets build [PATH]		sweets build [PATH]

Alsroot: /* Developing activities */

2011-12-06T21:18:57Z

Developing activities

← Older revision		Revision as of 17:18, 6 December 2011
Line 217:		Line 217:
	=== Developing activities ===		=== Developing activities ===

	The regular way for development related routines regarding activity sources is runing {{Code\|setup.py}} script located in the root activity directory. With Sweets, all ~~this~~ routines might be ~~be done suing~~ {{Code\|sweets}} command. The reasons are:		The regular way for development related routines regarding activity sources is runing {{Code\|setup.py}} script located in the root activity directory. With Sweets, all these routines might be used with {{Code\|sweets}} command. The reasons are:

	* The downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (to have all libraries that {{Code\|setup.py}} injected);		* The downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (to have all libraries that {{Code\|setup.py}} injected);
	* Sweets is designed to support multiple software versions at the same time, it ~~might be~~ not useful to ~~loging~~ to ~~every~~ Sugar session for creating, e.g., source tarballs; In other words, having standalone utility makes more sense;		* Sweets is designed to support multiple software versions at the same time, it is not useful to login to different Sugar session for creating, e.g., source tarballs; In other words, having standalone utility makes more sense;
	* {{Code\|sweets}} command already contains development related functionality, it is useful to keep all development related functions in one utility.		* {{Code\|sweets}} command already contains development related functionality, it is useful to keep all development related functions in one utility.

Alsroot: /* Developing activities */

2011-12-06T20:32:28Z

Developing activities

← Older revision		Revision as of 16:32, 6 December 2011
Line 232:		Line 232:
	And don't support the following:		And don't support the following:

	* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources, the same might be done using {{Code\|ln -s}} command to avoid having derived functionality, or better, ~~place~~ source exactly to {{Code\|~/Activities}} directory;		* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources, the same might be done using {{Code\|ln -s}} command to avoid having derived functionality, or better, places source exactly to {{Code\|~/Activities}} directory;
	* {{Code\|fix_manifest}}, function create {{Code\|MANIFEST}} file, not having this file is not a fail and Sweets is designed to have include/exclude rules in recipe files instead;		* {{Code\|fix_manifest}}, function create {{Code\|MANIFEST}} file, not having this file is not a fail and Sweets is designed to have include/exclude rules in recipe files instead;
	* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the regular behaviour.		* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the regular behaviour.

Alsroot: /* Developing activities */

2011-12-06T20:19:49Z

Developing activities

← Older revision		Revision as of 16:19, 6 December 2011
Line 232:		Line 232:
	And don't support the following:		And don't support the following:

	* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources, the same might be done using {{Code\|ln -s}} command to avoid having derived functionality;		* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources, the same might be done using {{Code\|ln -s}} command to avoid having derived functionality, or better, place source exactly to {{Code\|~/Activities}} directory;
	* {{Code\|fix_manifest}}, function create {{Code\|MANIFEST}} file, not having this file is not a fail and Sweets is designed to have include/exclude rules in recipe files instead;		* {{Code\|fix_manifest}}, function create {{Code\|MANIFEST}} file, not having this file is not a fail and Sweets is designed to have include/exclude rules in recipe files instead;
	* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the regular behaviour.		* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the regular behaviour.

← Older revision		Revision as of 18:42, 6 December 2011
Line 223:		Line 223:
	* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.		* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.

	Sweets support the following {{Code\|setup.pu}}'s commands:		Sweets support the following {{Code\|setup.py}}'s commands:

	* {{Code\|build}}, build generated files, e.g., {{Code\|locale/}} directory;		* {{Code\|build}}, build generated files, e.g., {{Code\|locale/}} directory;

← Older revision		Revision as of 18:25, 6 December 2011
Line 217:		Line 217:
	=== Developing activities ===		=== Developing activities ===

	The ~~regular way for~~ development related ~~routines regarding~~ activity sources is ~~runing~~ {{Code\|setup.py}} script located in the root activity directory. With Sweets, ~~all~~ these routines might be ~~used~~ with {{Code\|sweets}} command. ~~The reasons are~~:		The traditional development related routine for activity sources is to run the {{Code\|setup.py}} script located in the root activity directory. With Sweets, these routines might be accomplished with the {{Code\|sweets}} command. Here is some background information:

	* ~~The~~ downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (to have all libraries that {{Code\|setup.py}} ~~injected~~);		* A downside of using Sweets is that running {{Code\|setup.py}} requires being in the Sugar session (in order to have all the libraries that {{Code\|setup.py}} injects);
	* Sweets is designed to support multiple software versions at the same time~~, it is not useful~~ to login to different Sugar ~~session~~ for creating~~, e.g.,~~ source tarballs~~; In other words~~, ~~having standalone utility~~ makes more sense;		* Sweets is designed to support multiple software versions at the same time. So to avoid having to login to different Sugar sessions for creating source tarballs, for example, it makes more sense to have a standalone utility;
	* {{Code\|sweets}} command already contains development related functionality, it is useful to keep all development related functions in one utility.		* The {{Code\|sweets}} command already contains development related functionality; it is useful to keep all development related functions in one utility.

	Sweets support the following {{Code\|setup.pu}}'s commands:		Sweets support the following {{Code\|setup.pu}}'s commands:
Line 232:		Line 232:
	And don't support the following:		And don't support the following:

	* {{Code\|dev}}, seems to be needlessly exaggerated, function creates symbolic link in {{Code\|~/Activities}} directory to activity sources~~, the~~ same might be done using {{Code\|ln -s}} command to avoid having derived functionality, or better, ~~places source exactly to~~ {{Code\|~/Activities}} directory;		* {{Code\|dev}} - seems to be a needlessly exaggerated function that creates a symbolic link in the {{Code\|~/Activities}} directory to activity sources. The same might be done using the {{Code\|ln -s}} command to avoid having derived functionality, or better, place sources directly in the {{Code\|~/Activities}} directory;
	* {{Code\|fix_manifest}}, function ~~create~~ {{Code\|MANIFEST}} file~~, not~~ having this file is not a ~~fail~~ and Sweets is designed to have include/exclude rules in recipe files instead;		* {{Code\|fix_manifest}} - function creates {{Code\|MANIFEST}} file. Not having this file is not a failure, and Sweets is designed to have include/exclude rules in recipe files instead;
	* {{Code\|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during ~~the~~ regular behaviour.		* {{Code\|install}} - function installs the activity to the root system. Sweets avoid, by design, any global changes during its regular behaviour.

	As regular {{Code\|sweets}}'s commands, these ~~command~~ need to be executed ~~being in~~ activity directory (in any of its sub-directories, not ~~only~~ in the root), or path to activity sources might be specified after command name, e.g.:		As regular {{Code\|sweets}}'s commands, these commands need to be executed from the activity directory (or in any of its sub-directories, not just in the root), or the path to activity sources might be specified after the command name, e.g.:

	sweets build [PATH]		sweets build [PATH]