On Mon, 2010-07-05 at 15:13 +0200, Tomeu Vizoso wrote: > Would be good to have some way of tracking what needs to be solved > before we can do the switch. Two questions off the top of my head are > how first-time activity authors are going to package their software
Now they do: ./setup.py fix_manifest ./setup.py dist_xo When we remove the manifest thing, they could do: ./setup.py dist_xo None of the activities I have seen so far store a manually generated MANIFEST in git. In case they'd need to exclude some files, hopefully setup.py would provide extensibility hooks. Actually, I've never seen a setup.py containing anything else than the two lines of copy-pasted code (plus the usual dozen lines of legal crap). Activities which need to build binaries, such as Physics, require a manual build step. This confirms my theory that the xo bundle format is so easy to use just because it doesn't do any of the things that a packaging system needs to do. Currently, setup.py is just a glorified "zip -r". > and also what those people will have to do to modify an activity > installed in their system. (But maybe not discuss these in this > thread?). Currently, upgrading an activity causes the new files to be merged with the old ones. This is clearly a bug that should be fixed. The MANIFEST doesn't play any role in activity installation. The version of Sugar shipped in F11-0.88 contains a patch that removes all this code and it is functionally identical from the user's point of view, apart from not logging warnings when the MANIFEST contains inconsistencies. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel