[sugar] Squeak / Etoys RPMs

[Marco Pesenti Gritti]

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