Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 217:

=== 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:

Line 232:

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]

@@ Line 217: / Line 217: @@
 === 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:
@@ Line 232: / Line 232: @@
 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]