zlib module missing - python 2.4.3 - python

I am trying to get simplejson installed on this python 2.4.3 - I cannot upgrade, I know it is old, there is nothing I can do about it, it is not my fault, please help. however when i do the ..\python.exe .\setup.py install i get:
File "C:\Program Files (x86)\WorldViz\Vizard30\bin\lib\zipfile.py", line 188, in __init__ raise RuntimeError,\
RuntimeError: Compression requires the (missing) zlib module
Does anyone know how can I get zlib installed on this windows 64 machine? or where I can get a compiled version of simplejson or where can I find a compatible alternative for it.
Again, I can't do anything about it being python 2.4.3 - it is a proprietary modified version of python that I cannot do a thing about.

Copying the .py files into site-packages will get some stuff to work - particularly you can read files from an uncompressed zip archive, but you will not be able to inflate compressed files. The problem you are having is that ./config is not finding zlib.so (or possibly zlib.h) where it expects to find it and skips making it. This is a problem in compiling old versions of Python (pre 2.6) on recent Ubuntu boxes (Natty Narwhal - 11.0 in particular) since Canonical restructured the /lib directory contents to better (for them) support multiple architectures. So config is looking for the file /lib/libz.so and it is in /usr/lib/i386-linux-gnu/libz.so (or some other /usr/lib/$ARCH/ directory depending upon your machine).
It is supposed to be possible to tell config additional directories to search by exporting shell variables. I couldn't get that to work. What did work was the nasty hack
ln -s /usr/lib/i386-linux-gnu/libz.so /lib/libz.so
There are other parts of the standard library that config considers optional that are affected by this, but I didn't have time to track them down. After you do "make" do a "make test" and at the end it will list which packages were expected on Linux that it did not find.

The zlib module comes in the Standard Library, and I do not see a separately installable version on the Python Package Index. It is actually integral to Python, since Python cannot run its own Standard Library without it if the library is distributed as a ZIP file, so this must be a very customized Python if it lacks it. Could you build normal Python from source in another directory and in the presence of the library files for zlib, and then copy the zlib.so file over to see if it will link against this crazy Python you are using?
Edit: And, come to think of it, why do you need a compiled version of simplejson? Is the plain Python version not enough?
Edit: Here is how I can install simplejson without trying to get its accelerator routine to compile:
$ wget http://pypi.python.org/packages/source/s/simplejson/simplejson-2.1.1.tar.gz
$ tar xvfz simplejson-2.1.1.tar.gz
$ cd simplejson-2.1.1
$ cp -r simplejson /usr/lib/python2.4/site-packages
Those first three steps can all occur on some other system, and of course you can just use your web browser rather than wget. But the point is that you can just copy the whole simplejson directory from inside of the .tar.gz into your site-packages and it should work. It's a messy way to manually install, but it sure won't depend on any other dependencies! :-)

Related

What is the python equivalent to a Java .jar file?

Java has the concept of packaging all of the code into a file called a Jar file. Does Python have an equivalent idea? If so, what is it? How do I package the files?
Python doesn't have any exact equivalent to a .jar file.
There are many differences, and without knowing exactly what you want to do, it's hard to explain how to do it. But the Python Packaging User Guide does a pretty good job of explaining just about everything relevant.
Here are some of the major differences.
A .jar file is a compiled collection of classes that can be dropped into your application, or installed anywhere on your CLASSPATH.
In Python:
A .py (or .pyc) module can be dropped into your application, or installed anywhere on your sys.path, and it can be imported and used.
A directory full of modules can be treated the same way; it becomes a package (or, if it doesn't contain an __init__.py, it merges with other directories of the same name elsewhere on sys.path into a single package).
A .zip archive containing any number of modules and packages can be stored anywhere, and its path added to your sys.path (e.g., at runtime or via PYTHONPATH) and all of its contents become importable.
Most commonly, you want things to be installed into a system, user, or virtualenv site-packages directory. The recommended way to do that is to create a pip-compatible package distribution; people then install it (and possibly automatically download it from PyPI or a private repo) via pip.
pip does a lot more than that, however. It also allows you to manage dependencies between packages. So ideally, instead of listing a bunch of prereqs that someone has to go download and install manually, you just make them dependencies, and someone just has to pip install your-library. And it keeps track of the state of your site-packages, so you can uninstall or upgrade a package without having to track down the specific files.
Meanwhile, in Java, most .jar files are cross-platform; build once, run anywhere. A few packages have JNI native code and can't be used this way, but it's not the norm.
In Python, many packages have C extensions that have to be compiled for each platform, and even pure-Python packages often need to do some install-time configuration. And meanwhile, "compiling" pure Python doesn't do anything that can't be done just as well at runtime. So in Python, you generally distribute source packages, not compiled packages.
However, .wheel is a binary package format. You can pip wheel to build binary packages for different targets from the source package; then, if someone tries to pip install your package, if there's a wheel for his system, that will be downloaded and installed.
Easy Install from setup_tools defines the .egg format for deploying Python libraries or applications. While similar to JAR, it is nowhere spread as universally as JARs in Java world. Many people just deploy the .py files.
A newer format, intended to supersede eggs, is wheel.
Though it's not a perfect susbstitute of jar due to portability issues, I would add the "auto-extracting" archive way.
One possibility is "makeself": https://makeself.io/
But if you don't need to package external files, and if you like KISS approach, the following is a nice and clean alternative:
The following is taken from Asim Jalis's website.
How to deploy a Python application as a zip file
Create a file __main__.py containing:
print "Hello world from Python"
Zip up the Python files (in this case just this one file) into app.zip by typing:
zip app.zip *
The next step adds a shebang to the zip file and saves it as app—at this point the file app is a zip file containing all your Python sources.
echo '#!/usr/bin/env python' | cat - app.zip > app
chmod 755 app
That’s it. The file app is now have a zipped Python application that is ready to deploy as a single file.
You can run app either using a Python interpreter as:
python app
Or you can run it directly from the command line:
./app
Reference: https://gist.github.com/asimjalis/4237534

Is there a way to embed dependencies within a python script?

I have a simple script that has a dependency on dnspython for parsing zone files. I would like to distribute this script as a single .py that users can run just so long as they have 2.6/2.7 installed. I don't want to have the user install dependencies site-wide as there might be conflicts with existing packages/versions, nor do I want them to muck around with virtualenv. I was wondering if there was a way to embed a package like dnspython inside the script (gzip/base64) and have that script access that package at runtime. Perhaps unpack it into a dir in /tmp and add that to sys.path? I'm not concerned about startup overhead, I just want a single .py w/ all dependencies included that I can distribute.
Also, there would be no C dependencies to build, only pure python packages.
Edit: The script doesn't have to be a .py. Just so long as it is a single executable file.
You can package multiple Python files up into a .egg. Egg files are essentially just zip archives with well defined metadata - look at the setuptools documentation to see how to do this. Per the docs you can make egg files directly executable by specifying the entry point. This would give you a single executable file that can contain your code + any other dependencies.
EDIT: Nowadays I would recommend building a pex to do this. pex is basically an executable zip file with non stdlib dependencies. It doesn't contain a python distribution (like py2app/py2exe) but holds everything else and can be built with a single command line invocation. https://pex.readthedocs.org/en/latest/
The simplest way is just to put your python script named __main__.py with pure Python dependencies in a zip archive, example.
Otherwise PyInstaller could be used to produce a stand-alone executable.
please don't do this. If you do DO NOT make a habit of it.
pydns is BDS licensed but if you try to "embed" a gpl module in this way you could get in trouble
you can learn to use setuptools and you will be much happier in the long run
setuptools will handle the install of dependencies you identified (I'm not sure if the pydns you are using is pure python so you might create problems for your users if you try to add it yourself without knowing their environment)
you can set a url or pypi so that people could upgrade your script with easy_install -U

Python fails after deleting site.py

tl;dr
I accidentally deleted my Python installation’s site.py file. Now, when trying to start Python, it complains,
ImportError: Couldn't find the real 'site' module
I tried downloading a site.py from setuptools but this results in an infinite recursion in the __boot method around the statement imp.load_module('site',stream,path,descr) (line 37).
Is there a way to fix this without reinstalling Python? What is the site.py file supposed to do?
Some background information:
This is on a Linux server with a custom Python installation in my home directory (~/nfs, to be precise). There are other Python installations on the server (not mine – it’s a mess!) but $PATH and $PYTHONPATH are set up in such a way as to find my installation first.
As to why I deleted the site.py file: I tried executing a setuptools setup.py script and the script told me to delete the file because it “was not created by setuptools”. I foolishly complied.
I suspect that this original error message was caused by the fact that the setuptools implementation is not mine.
The site module sets up your python module search path and some other things. It is somewhat crucial to the normal operation of python.
You can download a new copy from the python source repository:
For python 2.7
For python 3.2
For other python versions, generally the URL is http://hg.python.org/cpython/file/*major*.*minor*/Lib/site.py for the correct tagged version, then select the raw link in the left-hand menu.
If you installed python from a linux distribution package on Ubuntu or Debian, then this file has been customized and you'll need to re-install the appropriate python-minimal package.

How to install Python in Linux without previous version installed

I'm currently doing some embedded systems programming. This was set up by somebody else a few years ago. So now I'm looking to upgrade to Python 2.7.2 to make things simpler because I have already run into two cases where what I coded wasn't supported.
What is currently running:
: uname -a
Linux host1 2.6.18-6-486 #1 Sun Feb 10 22:06:33 UTC 2008 i586 GNU/Linux
: python -v
Python 2.4.4
: pyversions -i
python2.4
So right now only 2.4 is installed.
I untarred python2.7.2 and when I go to that directory and run python27 setup.py install --home=/home/jhemilian and it seems like python2.4 doesn't seem to know the with...as statement syntax:
host1:/home/jhemilian/src/Python-2.7.2: python setup.py install --home=/home/jhe
milian
File "setup.py", line 361
with open(tmpfile) as fp:
^
SyntaxError: invalid syntax
Before I go figuring this out I first have a question: python itself is being used to install Python? What if I didn't have the first version of Python installed? I know it's shipped with most Linux but hypothetically -- how does such a seeming catch-22 like that work?
What I am looking to do is install python2.7 in a benign location, keeping the python command still as using Python 2.4 just in case the "legacy" software i'm running is dependent on it, and running python2.7 myscript.py et cetera when I want to run one of my newer scripts. Feel free to comment if there is a cleaner or more practical (or even safer!) way to do this.
I don't think it would make much sense to go replacing all the with statements with compatible try blocks. I've looked though the READMEs and online documentation but I can't seem to find a way to install Python without already having Python. Note that I DO NOT have internet connection, although if desirable or necessary I could. It would be great if somebody could point me in the right direction. Thanks!!
It's all right in the README...
You don't need to use python to install, in fact, you shouldn't...just:
./configure
make
make install
If you want to install in a specific dir, just follow what the README says:
Installing
To install the Python binary, library modules, shared library modules
(see below), include files, configuration files, and the manual page,
just type
make install
This will install all platform-independent files in subdirectories of
the directory given with the --prefix option to configure or to the
prefix' Make variable (default /usr/local). All binary and other
platform-specific files will be installed in subdirectories if the
directory given by --exec-prefix or theexec_prefix' Make variable
(defaults to the --prefix directory) is given.
If DESTDIR is set, it will be taken as the root directory of the
installation, and files will be installed into $(DESTDIR)$(prefix),
$(DESTDIR)$(exec_prefix), etc.
All subdirectories created will have Python's version number in their
name, e.g. the library modules are installed in
"/usr/local/lib/python/" by default, where is the
. release number (e.g. "2.1"). The Python binary is
installed as "python" and a hard link named "python" is
created. The only file not installed with a version number in its
name is the manual page, installed as "/usr/local/man/man1/python.1"
by default.
If you want to install multiple versions of Python see the section
below entitled "Installing multiple versions".
The only thing you may have to install manually is the Python mode for
Emacs found in Misc/python-mode.el. (But then again, more recent
versions of Emacs may already have it.) Follow the instructions that
came with Emacs for installation of site-specific files.
EDIT: virtualenv is apparently for already-installed Python versions. Disregard this recommendation.
I think what you want is virtualenv.
I haven't used it myself, but I understand this is what it's meant for.
From the website:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
EDIT: Upon review, I think you want Alberto's answer, so I voted him up for visibility.

Python on AIX: What are my options?

I need to make some Python applications for a work project. The target platform is AIX 5.3.
My question is: What version of Python should I be using?
My requirements are:
The Python version must be easy to install on the target machines. Others will do that according to instructions that I write, so no compiling from source or anything like that.
The Python version must have ncurses or curses support (I'm making a form handler).
I've found two different precompiled versions of Python for AIX, but one (2.1.something) didn't include the curses module, and the other (2.3.4, RPM format) had prerequisites that I failed to fulfill).
Any help would be greatly appreciated.
Use the AS Package of Python 2.6.3.7 from Activestate. They have a binary package for AIX on their download site.
If you don't have an AIX machine to test it on, the install works the same way on Solaris or Linux, so you could write your documentation based on that. Basically, you ungzip the tarball file, use tar to unpack the archive, change directory to the unpacked folder, run a shell script to install it, tell the shell script what directory to place it in, and wait.
Normally this would be used to install into a user directory, without superuser permissions, but you could install it anywhere that you like. You might also need to edit the system profile in order to make sure that all users can find the Python binary.
I suggest the latest Python 2.6, because it has a lot of bugfixes, and there is now a critical mass of 3rd party libraries ported to it. Also, the standard library includes a lot of useful stuff that you used to have to collect separately. Curses is in the standard library of Python 2.6.
Make sure to avoid Python 3.1 since it has not yet matured enough and provides few benefits for most business applications development.
I'd compile it from source myself and tell them where to download it from in the instructions
We've used ActiveState's Python as well as Pware's compiled version. Both have worked well. For AS, we've used 2.5 and 2.6. For Pware, just 2.6. Both 2.5 and 2.6 from AS support curses on our machine.
I've compiled from source but usually wind up having trouble with with ctypes or SSL. Currently I have the Frankenstein option going of AS Python2.6 installed but I pulled out a couple of *.so files from Pware's. I'm using GCC since we've never ponied up for a compiler but depending on what you need from Python, it's definitely doable if I can do it.
I will mention that AS Python claims to be 100% compatible with standard Python and it has been for everything we've done so far (mostly web applications).

Categories