Ian Bicking wrote:
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
Yeah.
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?
At the moment the user experience design doesn't require these, as far
as I know. We can add them later if necessary.
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.
I didn't put a lot of thinking into this. Dan might have better input.
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.
The whole discussion was about the build process, not about the bundle
format or it's metadata. That's a given, we have a spec for it (but we
are obviously open to improvements).
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.
Well etoys is a python based activity, in some sense.
http://dev.laptop.http://dev.laptop.org/git.do?p=projects/etoys;a=tree
The activity itself is written in python, even if it looks like a
wrapper around the real code (which I assume is etoys.image). I'm not
sure I see the point to write custom scripts (or even worst build the
bundle every time by hand) in this case. setuptools should be perfectly
capable to put together a few data files (the svg, the image, the bundle
info) and a couple of python files in a bundle.
Anyway I don't know what are the plans for etoys, I'm just looking to
the current code. So it might be that setuptools is not the right tool
to package it. The point is that we need to start packaging activities
as bundles and it make sense to start from the most common case, i.e.
python based activities.
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
