Platform Team/Guide/Sweets Packaging: Difference between revisions

Line 214:

and see its {{Code|sweets.recipe}} files.

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

* {{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:

* {{Code|build}}, build generated files

* {{Code|dist_xo}}, create a .xo with activity sources

* {{Code|dist_source}}, create activity sources tarball

* {{Code|genpot}}, generate the gettext pot file

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|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;

* {{Code|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the 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:

sweets build [PATH]

== Good practices ==

@@ Line 214: / Line 214: @@
 and see its {{Code|sweets.recipe}} files.
+=== 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 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;
+* {{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:
+* {{Code|build}}, build generated files
+* {{Code|dist_xo}}, create a .xo with activity sources
+* {{Code|dist_source}}, create activity sources tarball
+* {{Code|genpot}}, generate the gettext pot file
+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|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;
+* {{Code|install}}, function installs activity to the root system, Sweets avoid, by design, any global changes during the 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:
+ sweets build [PATH]
 == Good practices ==