[Chandler-dev] Integrating Egg-based parcels in 0.7alpha2

[Phillip J. Eby]

At 12:17 PM 3/22/2006 -0800, Heikki Toivonen wrote:
>Phillip J. Eby wrote:
> > Egg-based Parcels in Chandler
> > =============================
> > For 0.7alpha2, we are only supporting the installation of plugins (and
>
>I have a question about naming. Are plugins different from parcels,

Quite.  :)  A plugin may contain zero or more parcels, and it is a unit of 
distribution rather than of code.  A parcel is the persistent 
representation of a Python module or package, as described here:

http://chandler.osafoundation.org/docs/0.6/parcel-schema-guide.html#what-are-parcels

So, it is possible to have non-plugin parcels, like the core parcels in 
Chandler currently.  Some other relevant definitions:

* A "project" is a collection of zero or more parcels and other resources 
(such as non-parcel Python code, images, etc.) that can be packaged as an 
egg for distribution and use with Chandler.

* A "plugin project" is thus a project that provides optional features

Note that in the future, a plugin project may in fact contain no parcels at 
all; it may just be a collection of translated messages or localized 
resources.  Such plugins may not even include any Python code, let alone 
parcels.

I'm not positive that the term "parcel" will actually be that enduring as a 
significant factor in Chandler development.  While it's useful for 
referring to the persistent representation of a module's schema and 
singleton items, there isn't much need to refer to it in introductory 
documentation.

Indeed, your bringing this up has made me realize that maybe the entry 
point group shouldn't be called "chandler.parcels", but maybe 
"chandler.components" or "chandler.schema_modules".  The term "parcel" 
isn't adding anything to anyone's understanding, outside of the small group 
of people who've been doing Chandler development to date.  Instead, it just 
raises the *question* of what a parcel is.

But, I think this can be changed at any time prior to the completion of 
0.7, so we don't have to rename it right away.  But it definitely bears 
some consideration of how the documentation and APIs should be structured, 
to avoid using the temr "parcel" anywhere except where it means "a Parcel 
object stored in the repository".  Right now, for historical reasons we are 
using the term somewhat more broadly than that, to also refer to the code 
that defines the parcel's contents.