[sugar] Squeak / Etoys RPMs

[Dan Williams]

On Mon, 2006-10-09 at 12:12 -0500, 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

This doesn't exist.  What the 'exec' line says is the command to run to
launch the actual activity.  We don't run anything on install.  The
activity should have everything it needs inside itself, and it should
not need to actively 'register' anything.  If something like that needs
to happen, it needs to be the metadata.

> * Maybe a routine to "run" the activity itself?  Or perhaps this is 
> registered by the installation routine

See above.

> * A deinstallation/deactivation routine

No :)  Why is this necessary?

> 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 

That's quite an open question.  And what's the mime-handler registry
for?  We don't have a desktop, so you don't really double-click to open
a random file.

> the machine starts up?  Or do we allow for just some particular things 

I don't think we want this right now.  If we really need it (for
"services" or something else that's long-lived) we need to figure out
what the use-case is, and how we enable services without a UI (like the
presence service).

> -- 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 

Not really.  Each activity has a 'service' name, which represents the
activity's DBus service.  There can only be ONE active dbus service of a
certain name at any given time (that's not entirely true, but we want it
to be).  If you try to install a bundle with the same 'service' name as
one that already exists, the install bits look at the 'activity_version'
key, which is an integer.  If the one you're trying to install has a
greater version, it's installed.  If it has the same or less, it's not
installed.

> 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 don't see having multiple bundles providing the same services as
necessary or wanted.  What was the use-case you were thinking of?

> And then there's a bunch of other issues when activities extend other 
> activities.

I also don't think we want this.  The whole point of activity bundles
was to be self-contained.  There will be a certain set of base Python
functionality installed on the OS along with Python, but beyond that,
you're on your own to package up the dependencies of your activity into
the activity itself.  Same with a C/C++ activity.  If you need some
random library that's not on the base system, you are responsible for
packaging that library up into your bundle and linking to it
appropriately (with RPATH or LD_LIBRARY_PATH or whatever).

Remember, we _may_ chroot into the activity's directory before executing
the activity.  Activity bundles will _also_ be read-only.  If the
activity needs to change anything, it must use the appropriate Sugar
profile path which is stored in the user's home directory.

These really are self-contained programs.  Think of an activity bundle
like a Java JAR file or applet that must contain everything it needs,
aside from the standard VM on the machine.

Dan

> 
> 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.
> 
>