Ross Boylan wrote: [...]
> I suspect that is the file the build process needs to turn into > pyskel.py (or maybe pyskel). The documentation referred specifically > to pyskel.py; given the state of Zope documentation, I suppose that's > only suggestive. > > First, *.in is usually reserved for files that will be processed by > configure so foo.in -> foo, with variables substituted. foo.in is for > the build system; foo is for the end user. > > Second, pyskel.in appears to include such substitution variables, like > SOFTWARE_HOME = r"<<SOFTWARE_HOME>>" > with <<SOFTWARE_HOME>> to be substituted. > I'm a little puzzled, because the normal syntax is @SOFTWARE_HOME@, > but maybe this file gets some non-standard preprocessing. > > At any rate, I don't think it will work too well until the > substitutions are made. The first line > #!<<PYTHON>> > will not invoke the python interpreter as it stands. > > Third, pyskel.in normally would produce pyskel, while pyskel.py.in > would produce pyskel.py. So maybe the intent is to produce an > executable pyskel. This seems a gratuitous change from previous > versions, and it may also complicated storing compiled (.pyc) code. > There's probably some debian policy about python that's relevant. That's why it's an .in - it's merely a template. Have you tried looking in $INSTANCE/bin? Consider this: $ sudo dzhandle -z3 make-instance test -m manual [dzhandle questions skipped] $ ls -l /var/lib/zope3/instance/test/bin/pyskel -rwxr-xr-x 1 zope zope 6214 2005-01-06 15:41 /var/lib/zope3/instance/test/bin/pyskel Cheers, Igor P.S.: $INSTANCE/bin also includes "test" (commonly refered to as 'test.py' in most z3 docs) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
