[sugar] Squeak / Etoys RPMs

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org