[PEAK] PEAK currently doesn't build from CVS on Win32

Phillip J. Eby pje at telecommunity.com
Tue Jul 13 14:46:37 EDT 2004


At 02:19 PM 7/13/04 +0000, Paul Moore wrote:
>The persistence module seems not to be present...

Perhaps you're working from an old checkout and not using -d when you 
update?  The current location of the persistence package is a new directory 
put in four weeks ago; if you had an older checkout and didn't update with 
-d, it won't have been created in your checkout.  Similarly, you may still 
have an empty directory at the old location of the package.  Generally 
speaking, it's best to update with '-dP', to purge empty directories and 
check out new ones, and so I do it all the time even when I know full well 
I haven't added or removed any directories.  :)


>Also, there's a nasty looking problem if you import peak.binding.api direct
>into a new Python instance. I suspect that it's because you need to import
>something else first, to get an import hook in place, but nevertheless, it's
>not good...
>
>I know, "Don't do that". But I wanted to import that module, just to do 
>help()
>on it to get some information. In that context, directly importing just the
>module you want to look at seems like a reasonable thing to try...

Interesting.  Apparently, the specific issue is that if the first place 
peak.core is imported from is peak.config.interfaces, the 'whenImported()' 
hooks in peak.core to declare the interfaces PropertyName supports, then 
this happens.  Probably the simple answer would be to take out the 
whenImported hooks and just stick them directly into 
peak.config.interfaces.  I seem to recall they actually were there once, 
but I moved them to be next to PropertyName for locality of reference.

In the meantime, import peak.core before anything else, and you'll be 
fine.  :)  Note also that 'from peak.core import binding' will return you 
the same module as peak.binding.api anyhow, and that's true for all the 
core API modules.




More information about the PEAK mailing list