Need Help with Efforts to Package PreScript 2.2
tags 167743 help
thanks
(Sending a copy to the debian-python mailing list in the hopes that
someone there can step in and help.)
To help Andreas Tille with getting all the prerequisites for work being
done on packaging the Zope DocumentLibrary product I attempted to
package PreScript.
I had problems with working out a proper packaging for Debian, and got
in touch with the New Zealand Digital Library administrator to get some
information. Stefan Boddie replied to my message. His reply is attached
at the bottom of this message. He quotes my original message correctly,
so I do not need to attach my original message anymore.
I cannot continue working on packaging prescript as I am very hesitant
to maintain a package for software that is effectively abandoned
upstream. Unfortunately I have neither the time nor the expertise to
take over upstream management of prescript at the moment.
--> Jijo
----- Forwarded message from Stefan Boddie <sjboddie@cs.waikato.ac.nz> -----
Message-ID: <3DE43604.1010406@cs.waikato.ac.nz>
Date: Wed, 27 Nov 2002 16:03:32 +1300
From: Stefan Boddie <sjboddie@cs.waikato.ac.nz>
Subject: Re: Efforts to Package PreScript 2.2 for the Debian System
References: <20021113102202.GA22111@leathercollection.ph>
Hi Jijo,
Sorry for the delay in responding, I've been away and it's taken some
time to catch up with my email.
>
> I am currently working to create a Debian package for PreScript 2.2 and
> ran into a number of issues which I was hoping to get your insights on.
> I hope you do not mind this email of mine, and that you are not too
> busy. This is fairly long, but I have put an effort into making it as
> readable as possible, and hope this helps you in helping me out.
>
I think it's great that you're interested enough in PreScript to do
this. Unfortunately I'm not going to be much help to you though. The
original perl implementation of PreScript was written in the early 90's,
well before I started here at Waikato University. The rewrite to python
was done around 4 years ago by a grad student who has since moved on to
places unknown.
So, PreScript has effectively been unsupported and unloved for the past
couple of years. In theory it's one of the projects I look after but in
reality the other, more active projects take precedence. I'm not a
python person and I've never had the time or inclination to more than
scratch the surface of PreScript.
Anyway, from the Debian packaging point of view I agree with most of the
points you make below.
> - To comply with Debian standards my package cannot place all the
> PreScript files in a directory by themselves, like the
> recommendation to put them somewhere in /usr/local goes. Instead
> it will be best (I think) to place the executable Python script
> 'prescript' in /usr/bin, and the non-executable Python library
> files in /usr/lib/site-python/prescript/.
>
> This site-python location is provided for by Python so that 3rd
> party scripts may place their library there. I have already tested
> and as long as an __init__.py is added, the prescript library
> files may be imported in any Python script under the prescript
> namespace, as in 'from prescript import io, misc, process'. Later
> calls to components of these modules do not have to be changed.
>
> Furthermore this should allow for the removal of the two-line
> wrapper prescript.sh, and I think removing that overhead will be
> good (although it is admittedly negligible).
>
> I do not know if Python 1.4 comes with a similar site.py
> functionality though, and hope to hear from you what you think of
> my proposal for this to be done upstream.
>
All sounds good. I'd tend not to worry about supporting very old
versions of Python.
> - PreScript 2.2 currently uses regex and regsub, both of which have
> been deprecated since Python 1.5.2 (or thereabouts). Both still
> exist and work even in Python 2.2, which is the default on Debian
> unstable and the version I will be testing things on, but every
> time PreScript is ran Python spews out warnings about this
> deprecation, and at the least it is fairly annoying. Most of the
> calls to regex and regsub seem to be easily replaceable by calls
> to the newer re, but I am having difficulty translating the three
> calls to regex.symcomp() in process.py:
>
> pageNoPattern = regex.symcomp("^ *\([^0-9]*\) *\(<page>[0-9]+\) *\\1 *$")
> headerPatternA = regex.symcomp("^ *\(<page>[0-9]+\) +CHAPTER +[0-9]+")
> headerPatternB = regex.symcomp("^ *[0-9]+\.\([0-9]+\.\)* +\([A-Za-z]+ +\)+ *\(<page>[0-9]+\) *$")
>
> Personally (and for Debian) I think it would be good to drop the
> use of these deprecated calls. However I do not know if you share
> this same view, depending on what older versions of Python you
> need to support on your end as well. I would like to know if you
> would be interested in this endeavor (in which I am most willing
> to contribute).
>
Again, I'd tend not to worry about old Pythons. Replace the calls to the
deprecated modules.
> Aside from the above migration questions I have one question that
> pertains to the PRESCRIPT_DIR environment variable and the significance
> of the prescript.ps and about_prescript.ps files. I had initially
> planned to treat both as documentation, thereby placing them in
> /usr/share/doc/prescript/. However I noticed that io.py seems to call
> prescript.ps in the line
>
> gspipe = os.popen("gs -q -dNODISPLAY -soutfile=%%stdout %sprescript.ps %s quit.ps" % (__main__.prescript_dir, psFilename))
>
> What does this do? A search through the sources shows that prescript_dir
> is only used in io.py in the above call and later in ARFFFormatter's
> start() method. However there is no arff-header file in the sources.
> Does this mean that prescript_dir is written to at some point during the
> program's lifecycle?
>
> Maybe instead of placing prescript.ps with the other documentation I
> should create a /usr/lib/prescript/ directory and place it there, also
> changing the prescript Python script a bit to hardcode this directory so
> that the later call (quoted above) in io.py works?
>
I have a vague recollection that prescript.ps is (or was) used to prime
gs in some way. You really need to do some experimenting to work out
what it's doing though, before deciding where it should live.
> Thank you very much for your time. I hope that you can help me out with
> the last few steps I have to do to come up with a useable package for
> the Debian community. A am confident at least a number of the users of
> Debian should have good use for your handy application.
>
Sorry I can't help you more.
Good luck and regards,
Stefan Boddie
----- End forwarded message -----
--
Federico Sevilla III : http://jijo.free.net.ph : When we speak of free
Network Administrator : The Leather Collection, Inc. : software we refer to
GnuPG Key ID : 0x93B746BE : freedom, not price.
Reply to: