[Dev] ContentModel, Calendar, Contacts, etc. reorganization/flattening

[Phillip J. Eby]

At 10:36 AM 7/28/2005 -0700, Alec Flett wrote:
>Phillip J. Eby wrote:
>>One of the 0.6 developer platform goals is to flatten our Python package 
>>hierarchy a bit,
>
>This is really great - I've been looking forward to this kind of change 
>for a while. The only thing I see that I'd like changed slightly from your 
>list is this:
>>osaf.contentmodel.calendar.Calendar.*   -> osaf.pim.calendar.*
>>osaf.contentmodel.calendar.Recurrence.* -> osaf.pim.recurrence.*
>Recurrence is really part of the Calendar and the filename split is really 
>just to break apart the logic within the module. Ideally we'd have 
>osaf.pim.calendar.CalendarEventMixin, osaf.pim.calendar.RecurrenceRuleSet, 
>and so forth. Is there an obvious convention in python (like import * 
>from... inside of __init__.py) to allow this to happen while still letting 
>Calendar.py and Recurrence.py remain seperate files within the 
>osaf.pim.calendar module?

Note that what I was proposing is to rename calendar/Calendar.py to just 
calendar.py, and the same for recurrence.  I was under the impression, 
however, that recurrence was supposed to be able to be used for tasks as 
well at some point, so maybe I'm confused...?


>On a related note, why osaf.pim? why not just "chandler"? I'm guessing the 
>argument is that you could reuse these objects outside of chandler, which 
>seems nice.. though even the osaf prefix seems superfluous to me..

It's common practice in Python projects of this size that also expose a 
development platform or framework to use a namespace package to prefix 
package names, e.g. twisted.*, zope.*, peak.*.  The second level name then 
usually exposes major functional areas, and then the third level is 
preferably all modules, and no further packages except for "*.tests" packages.

The namespace prefix allows the use of rather general names, while 
lessening chances of collision with projects that want to reuse code from 
the platform.

In the long term I'd like to see package names like 'crypto' and 
'application' also get folded under the 'osaf' umbrella for this reason, 
but that needs to wait until our parcel management is no longer dependent 
upon the 'parcels/' directory system and we have good support for namespace 
packages.


>So on a related note, I'd like to propose some future renames after you're 
>done with this one
>(and maybe you've already thought about this)

A little bit.  I'm reluctant to take on too much at once, before the areas 
in question have "settled" enough to allow choosing good names.  I think 
osaf.contentmodel is a no-brainer, but a lot of other pacakges I don't feel 
nearly as certain about, and would like to give any renaming ideas some 
time to develop further.  We really don't want to thrash names, and I would 
hate to change a bunch of stuff only to discover a month later that we made 
a mistake and need to change it all again.  I've been thinking about the 
contentmodel->pim thing for like 4 or 5 months now and only in the last 
month or two have I been seriously proposing it.  So, lets give these other 
ideas a little time to mature, and we should get some experience about what 
we actually like/dislike from doing the contentmodel and using the result.