[TransWarp] RFC: PEAK package organization, continued

[Phillip J. Eby]

Hi all.  A couple of quick questions/proposals regarding PEAK's package 
layout...


Module Inheritance API
----------------------

Right now, all the module inheritance implementation lives in 
peak.api.modules, and is exported in peak.api.  It sort of seems that this 
should live in peak.binding.modules, and be exported in peak.binding.api, 
such that the following name changes would apply:

setupModule()  -> binding.setupModule()
adviseModule() -> binding.extendModule() # name change to purpose orientation
configure()    -> binding.configure()

ModuleInheritanceWarning -> binding.ModuleInheritanceWarning

__proceed__ would be made available from peak.api, because it needs to be 
un-prefixed for its normal, correct usage.

Modules internal to PEAK could import directly from peak.binding.modules if 
other peak.binding modules depended upon them.

Does anybody have any opinions one way or the other on this?  Any 
suggestions for better names of the individual functions?


Proposed 'deployment' package
-----------------------------

We'd like to merge most of the AppUtils and MetaDaemon packages' 
functionality into PEAK.  BUT, I'd like to avoid having a huge number of 
top-level packages in PEAK, like 'peak.logging', 'peak.config', 
'peak.daemons', blah blah blah.

I propose we put all of it into a 'peak.deployment' package whose scope 
would include utilities related to an application's deployment environment, 
such as:

* application configuration from __main__, environment, config files, or 
peak.naming providers

* I18N/L10N support

* logging, queueing, locking, stat counters, and similar operational facilities

* metadaemons

* database drivers???

* distribution/installation facilities, such as any PEAK-specific distutils 
extensions, documentation generation tools, etc.


Most of the above items will have relatively narrow API scopes, with few 
items to be exported in the peak.deployment.api module.  The vast majority 
of these items in fact will primarily be exported to the 
peak.naming.factories URL scheme registry, for creation via naming.lookup() 
or binding.bindTo().  It is also possible that in some cases, 
peak.deployment.api or peak.api will export lazyImport()s of a deployment 
subpackage API module.

Comments, anyone?  Is this too broad a scope?  Is there a better name than 
peak.deployment?  Anything that should be added or removed from the 
proposed scope list?

So far, the proposed PEAK overall layout looks like this:

peak.api         - quick access to API functions and subpackage API's
peak.binding     - tools for connecting and instantiating components
peak.naming      - interpretation of names and their referents
peak.model       - structural components of an application's domain model
peak.deployment  - interfacing with the environment an app lives in

(This is ignoring, peak.metamodels, peak.tests, and peak.util, which are 
not normally used by applications at this time.)

Thoughts?  Are we headed in the right direction?