[Zope-CMF] dev question on CMFDefault.__init__.py

[hazmat]

On Monday 21 October 2002 08:29 am, Tres Seaver wrote:
> On Mon, 2002-10-21 at 19:57, hazmat wrote:
> > On Monday 21 October 2002 07:22 am, Tres Seaver wrote:
> > > On Mon, 2002-10-21 at 09:02, Mark McEahern wrote:
> > > > [Florent Guillaume]
> > > >
> > > > > As one datapoint, the main body of __init__ is called at module
> > > > > initialization, which is very early. initialize() is called by
> > > > > Product initialization, which is done later by Zope.
> > > > >
> > > > > But I don't know the precise details of ZClasses initialization
> > > > > (and frankly the less I hear about ZClasses, the happier I am).
> > > >
> > > > Here are a couple of concrete questions I have:
> > > >
> > > > 1.  On line 110, a module level variable is created to store globals,
> > > > but then it's not used:
> > > >
> > > >     cmfdefault_globals=globals()
> > > >
> > > >     Why is that assignment even there?
> > >
> > > So that other modules can import it, and use it to find where on the
> > > filesystem the CMFDefault product lives.
> >
> > i've always wondered why this doesn't use package_home to leave the
> > actual path, instead of saving a reference to the globals... any
> > particular reason? all the things that take globals, take a path prefix
> > as well.
> >
> > at this point its probably moot, as its already been sacrificed on the
> > alter of backwards compatiblity.
> >
> > <snip>
> >
> > > > [hazmat]
> > > >
> > > > > many things are non obvious when your using talking about zclasses,
> > > > > imo. i'd imagine the placement of the initialziation stuff is
> > > > > either chance, or because of ordering requirements.
> > > >
> > > > This seems very fragile, then, insofar as CMFDefault is intended to
> > > > be a demonstration of CMF.  I would love to help improve it, but I'm
> > > > trying to understand it first.  <wink>
> > >
> > > Some of the cruft there comes from working around problems with
> > > order-of-initialization issues for ZClass-based development.  "Fixing"
> > > it is problematic, as the symptoms are tough to reproduce (they can
> > > depend, for instance, on the physical order of directory entries in the
> > > 'Products' directory!).
> >
> > i think by physical order, you really meant lexographical sort order of
> > directory name strings as according to python :-)
>
> Nope, I mean the order that the names come back when iterating over
> and opened directory, which varies based in the underlying C libraries;
> for instance, I have beaten my head against a problem where a fresh
> checkout had different behavior than an old sandbox, because the old
> sandbox was created before a particular directory was added to CVS;
> that product was then processed last, rather than in any "natural"
> order.

thats very strange, esp. considering that product initialization does an
os.listdir() and then a sort() on the resultant list.

/me bemoans x-platform compatiblity.

<snip>

>
> > >   - We are working on a tool for a current consulting gig which
> > >     synchronizes tool configurations between the filesystem and the
> > >     ZODB, using XML files to represent the serialized configurations.
> > >     The tool also manages other "setup steps" as callables, and keeps
> > >     track of "last run" times, as well as dependencies.  We probably
> > >     won't have time to release this tool in the near term, but I think
> > >     that (perhaps in conjunction with Adrian's tool) it would go a
> > >     long way toward solving the "site configuration management" issue.
> >
> > sounds very cool, part of the this is in public cvs
> > http://cvs.zope.org/Packages/ZConfig/
>
> Nope;  that would be *another* customer gig. :)  From a distance,
> ZConfig seems aimed more at "server" configuration, and less on "site"
> configuration (I could be wrong. :)

check, at least the right hand is aware of the left hand. ;-)


> > whats more interesting (as least to me ;-) is that i wrote something very
> > similiar for a client to solve the same problem (perhaps for different
> > reasons). i'll open source it latter today. i've been holding off because
> > i haven't made the time to document it, but as there is a real need i
> > think for this type of software, i'm just going to release it. i eschewed
> > xml (as it appears zconfig does), and focused generically on assembling
> > functions into structures (graphs, trees, sets) with logging,
> > dependencies, and structure nesting.
>
> Cool.

its released

http://www.zope.org/Members/k_vertigo/Products/TaskEngine

its more of a build engine than a synchronization tool

http://www.zope.org/Members/k_vertigo/Stories/TeamZope

has a paper i wrote that explains why i wrote it.

overall i need to polish it off some more and document it...

cheers,

kapil