[sugar] Python: distutils, setuptools, packages, etc
Thu Sep 28 14:13:55 EDT 2006
Dan Williams wrote:
> Take a look at the activity bundle proposal:
> It's important to note that this is not _only_ for python. But for
> activities, we really, really want to have a single layout that's in a
> single directory, and may be easily archived & compressed for transport.
> We also want bundles that are signed, like JARs, to ensure integrity.
> The idea is that as long as the activity (whether in Python, C, C++, or
> whatever) follows the bundle format, we don't care what it does
> internally for its structure.
Right. I'm thinking about a Python-specific build process for
activities, which creates something that is not Python-specific. A
Python-specific build process is desirable because it can be simple to use.
> Eggs sound like this, but since they don't appear to work for non-python
> code, we probably can't make them the actual bundle format. You could
> obviously us an egg _inside_ a bundle though.
I wouldn't expect eggs to be the bundle format. Bundles would typically
include several eggs anyway, since we'd be including the dependencies.
So, I'm guessing that an olpc_bundle command would create:
activity.info # copied from MyCode/mycode/mycode.activity ?
Potentially activity.info could be created from metadata kept elsewhere.
Or maybe not, I'm not sure. For instance, the "exec" key is something
I think should be automatically generated (since there will be an
up-front sys.path fixup to activate the eggs, then calling some function
in MyCode). Maybe that's what sugar-activity-factory does?
I'm inclined to say the activity.info file should be mostly generated,
though maybe based off an incomplete mycode.activity file.
Would it be possible for on activity bundle to contain multiple
activities? This seems possibly useful.
Once the bundle is created, I assume it is up to the system to manage it
and do everything else, so the build process only has to create a
> Also note that we may very well make the activity directory read-only
> and enforce that. Activities should _NOT_ expect to be able to write to
> their own directory, but instead should store their state elsewhere, in
> a Sugar-provided area or in the storage framework which Ivan is doing.
Eggs are expected to be read-only so that's no problem.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Sugar-devel