|
Thanks John. I haven't given up, I am just working on several component
issues at the same time. So, I appreciate your pointers. In this
particular case, I think I *might* be able to skip Cheetah completely
because I don't plan to use that particular feature in the app I am
attempting to install on IBM i. I am not sure yet because the database
portion of the app, the most important piece, can't be installed because
of the way the MySQL was compiled on IBM i (the version included with
PHP) and the alternative, sqlite, can't be used because of the way that
Python was compiled for IBM i. Kevin gave me a couple of workarounds
that involved installing either a different MySQL or a different Python,
but I am *trying* to use the "off the shelf" stuff that a typical IBM i
OSS user would have. It is already a bit daunting to get the IBM i OSS
stuff running without having to install a bunch of workaround packages
that make IBM i OSS less attractive (IMHO).
I am not a Python geek by any stretch but I always enjoy tackling a new
project so right now I am hacking some of the database code for the app
and seeing of I can get it to happily use the ibm_db module which would
be cool, but not knowing the app's internals, might be a stretch.
I WILL use your approach if the app requires the use of Cheetah, but I
think I can get away with not installing it. I won't know until I can
get a successful DB connection.....
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
Twitter - Sys_i_Geek IBM_i_Geek
On 12/30/2016 9:42 AM, John Yeung wrote:
Pete,
Sorry for the late response; don't know if you already found a
workaround or if you've given up.
Cheetah is essentially a pure-Python package. There is one optional C
module (which serves as a high-performance replacement for
NameMapper.py). Cheetah runs fine without it. So if you just ignore
that piece of it, you can "install" Cheetah the traditional low-tech
way, which is to fully unpack the compressed tarball (you can find it
at <https://pypi.python.org/pypi/Cheetah/2.4.4>), find the "cheetah"
directory, and move or copy that to a place on the Python search path,
typically the site-packages directory.
(Note that there is a directory within cheetah that contains both
"cheetah.h" and "Cheetah.h" as two distinct files. Clearly this was
meant for a full-blown Unix or Linux, and can't exist in the IFS.
Depending on what you're using to unpack the tarball, you may be
prompted to overwrite one with the other. Go ahead and do so.
Ultimately, that directory will be ignored anyway because it's just
for building the C module I mentioned.)
Now, bear in mind I don't actually use Cheetah myself. I'm just
speaking as someone who (because I use iSeriesPython) only has the
"dump the package source into site-packages" method of installation
available.
If you plan on using Cheetah in a standalone capacity, you may also
want to put the contents of the included bin directory into a place on
your QSH or PASE path (not the Python search path). They are intended
to be executable scripts.
Finally, I will note that while Cheetah was generally a very
well-liked package, it hasn't been maintained in years, and never made
the transition to Python 3 support (which I suppose is why you're
using Python 2.7 for this). I take it you don't really intend to use
Cheetah yourself, but rather need it as a dependency for something
else? (Because if you want a templating engine for your own use, there
are definitely other choices.)
John Y.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
