Marco Pesenti Gritti wrote:
Ivan Krstić wrote:
Marco Pesenti Gritti wrote:
* How do we pack executable code and resources in an activity bundle?
distutils, setuptools, auto*, something else? I don't think we want to
force people to use *one* build system but there should be at least a
suggested/documented one.
Right. So, it sounds like all of these systems will need to get extended
to support our bundle format; let's pick one to begin with, and do the
rest later (and the community might contribute them). I'd trust Ian's
judgment on picking an initial build system to bootstrap.
Yeah, I don't think auto* is going to be a good base anyway and Ian's
plan about setuptools made sense to me. Now, if Ian could work with Bert
to port the etoys activity over setuptools, I think that would be a good
basic test of his plan (the etoys activity looks really simple to
"package").
This doesn't make sense to me. Here's how I see the situation:
Activity bundles are a format. That format includes:
* How to recognize a bundle (e.g., on a Mac the bundle name must end in
".app")
* What the internal directory structure of the bundle is
* Where metadata goes, and in what format
* If there is a signature process, then what gets signed and where that
signature goes
The metadata is the hard one. Currently there seems to be:
* An icon and a name (both internationalized)
* A routine to run when the activity is installed
* Maybe a routine to "run" the activity itself? Or perhaps this is
registered by the installation routine
* A deinstallation/deactivation routine
This list seems much too short to me. A central registry of things like
mime handlers seems important. Do we allow for scripts to be run when
the machine starts up? Or do we allow for just some particular things
-- for instance, a declaration that the activity should handle certain
events when they appear on the bus? Since a bundle implies that more
than one bundle providing the same (or equivalent) functionality can be
on the machine at one time, there has to be management above this. Does
that management simply detect conflicts, and activate one bundle and not
the other? Or does every aspect where activities conflict get managed
separately? For instance, you could reasonably want two bundles to both
get an event. Or you can ask the user what the do when a certain file
type has to be handled.
And then there's a bunch of other issues when activities extend other
activities.
Anyway, these are the bundle questions. The build process is entirely
separate, and I wouldn't actually consider it very related.
There's also setuptools. I think setuptools is a good way of building
Python-based activity bundles. I don't think it has anything to offer
for non-Python systems. For something like EToys, very possibly the
right thing is to simply create the bundle by hand, or with a small
number of scripts that fit with the EToys/Squeak release process.
Another useful build tool might be a simple skeleton creator, that asks
a few questions and sets up the appropriate directories and some
well-commented example config files.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
