[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