Bug#337354: [Pkg-zope-developers] Bug#337354: zope3: add pyskel.py

Ross Boylan RossBoylan at stanfordalumni.org
Fri Nov 18 18:35:12 UTC 2005


On Fri, Nov 18, 2005 at 11:14:11AM +0100, Fabio Tranchitella wrote:
> Il giorno gio, 03/11/2005 alle 18.59 -0800, Ross Boylan ha scritto:
> > Package: zope3
> > Version: 3.1.0-3
> > Severity: normal
> > 
> > The package seems to lack pyskel.py, which is present in earlier Zope
> > packages and in the current Zope 3 svn sources.  Development is
> > possible without the file, but easier with it.
> 
> Hi Ross,
>   isn't /usr/lib/zope3/zopeskel/bin/pyskel.in the file you are 
> looking for?
> 
> Thanks,

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.





More information about the Pkg-zope-developers mailing list