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).
Related
I thought it is an easy question but I spent a lot of google time to find the answer with no luck. Hope you can help me.
My company has a large SW system on windows which is portable, meaning copy some folders, add some folder to windows path and you are ready to go.
No registry, no dll in system directory, no shortcuts, Nothing!
I want to start using python 3.x in our system in the same paradigm. I also want the ability to add to this distribution a pip/conda 3rd packages from time to time.
I don't want to install python msi on all the systems.
I don't want to pack it to standalone executable like py2exe and pyinstaller or use special python distribution like PyWin32.
Somehow, I couldn't find a formal official solution for that.
The closest thing was here but no pip is supported, python is minimal, and the system isolation is "almost".
3.8. Embedded Distribution New in version 3.5.
The embedded distribution is a ZIP file containing a minimal Python
environment. It is intended for acting as part of another application,
rather than being directly accessed by end-users.
When extracted, the embedded distribution is (almost) fully isolated
from the user’s system, including environment variables, system
registry settings, and installed packages. The standard library is
included as pre-compiled and optimized .pyc files in a ZIP, and
python3.dll, python36.dll, python.exe and pythonw.exe are all
provided. Tcl/tk (including all dependants, such as Idle), pip and the
Python documentation are not included.
Note The embedded distribution does not include the Microsoft C
Runtime and it is the responsibility of the application installer to
provide this. The runtime may have already been installed on a user’s
system previously or automatically via Windows Update, and can be
detected by finding ucrtbase.dll in the system directory. Third-party
packages should be installed by the application installer alongside
the embedded distribution. Using pip to manage dependencies as for a
regular Python installation is not supported with this distribution,
though with some care it may be possible to include and use pip for
automatic updates. In general, third-party packages should be treated
as part of the application (“vendoring”) so that the developer can
ensure compatibility with newer versions before providing updates to
users.
Any ideas?
Thanks.
How about... installing Python in one machine and replicate that installation on others computers?
Usually, I install Python in a Windows Virtualbox machine (Microsoft usually give it for free to try it or for testing old Internet Explorer versions).
Then I copy the Python directory to my Windows machine (the real host) and usually works. This makes possible to using various python versions.
Did you try to complete the Python Embedded Distribution? Usually they not come with Tkinter, but once I could copy files and put in this distribution in a way that works. Try it too.
You can install pip with get-pip.py
I'm a complete beginner learning Python. I noticed the Windows installer for Python states "does not include source" and below it there's an option to install the source via tarball.
http://www.python.org/getit/
What is left out if I install it with the windows installer without the source?
The source code.
This can be useful as a reference, or if, for example, you are doing Cython development (where you need the source to compile against).
In general though, the source isn't needed for the average Python user. If you need it, you'll know about it.
I have the following problem. I need to distribute our own version of python with some magic in it. In order to do this, the process is the following:
I build the python interpreter (on a redhat linux)
install it somewhere
tar.gz the whole thing
when it's time to make the user-package, unpack the tar.gz into the directory which will become the user package
tar.gz the user package directory
put the tar.gz on the web
This is the method I have to use. Good, bad? I don't know, I have little experience as a packager, and in any case I can't propose a change. This is the way they always did.
It turns out that when the user unpacks this tar.gz on suse, and tries to run the python setuptools (which has been installed together with python), the hashlib module raises an exception. What I found out is that building python on redhat, the python configure script finds the openssl library, which in turns makes it skip the building of the shamodule.c, md5.c and so on, and compiles hashmodule.c to attach to the openssl library. apparently, the openssl 0.9.7 on suse and the 0.9.8 on redhat are somehow different, meaning that, for some reason, the _hashlib module, when imported on suse, raises an import error, leading hashlib try to import _md5, _sha, _sha256, which are not there because on the redhat there was no reason to compile them (since openssl was jolly good there).
Does anyone know how to solve this problem. As I said, my experience as a packager is the bare minimum, so any hint and proposal are welcome, and I will try to deploy it as much as I am allowed by our legacy.
Does anyone know how to solve this problem.
You can't, really. If it's not the OpenSSL library that's a problem, it could be the C library itself, or some other critical component. Your best solutions are either:
(A) Build a version of Python for each operating system you wish to support, or
(B) Rework your code to use the native system Python on each platform.
Your alternative is to create a completely self-contained build environment so that when building under RedHat you're not using the system OpenSSL library, but are instead using one that you built yourself. This will work for just about everything other than the C library, but it can be tricky to set up. The idea is to minimize the relationship between your package and the system libraries.
If you're only supporting RedHat and SUSE, you could conceivably pursue option (A) by crafting an appropriate spec file and building binary packages for each platform. This would be a nice way to package everything up.
You should consider distributing a source RPM of your version of Python, rather than a binary tarball. You can take an existing Python release and repackage it with a patch of your changes. There's more detail on how to do this in the RPM Book.
On Tiger, I used a custom python installation to evaluate newer versions and I did not have any problems with that*. Now Snow Leopard is a little more up-to-date and by default ships with
$ ls /System/Library/Frameworks/Python.framework/Versions/
2.3 2.5 2.6 #Current
What could be considered best practice? Using the python shipped with Mac OS X or a custom compiled version in, say $HOME.
Are there any advantages/disadvantages using the one option over the other?
My setup was fairly simple so far and looked like this: Custom compiled Python in $HOME and a $PATH that would look into $HOME/bin first, and subsequently would use my private Python version. Also $PYTHONPATH pointed to this local installation. This way, I did not need to sudo–install packages - virtualenv took care of the rest. Note: I liked this setup, so I'm just curious and thought I inquire the hive mind.
I guess it depends on your needs. Personally, I use the latest version for any series (2.5, 2.6, etc.) from MacPorts.
I compile it myself because this gives me the newest 64-bit version. The official OS X builds seem to be 32-bit only. I dropped MacPorts several months ago because its dependency system and its often outdated packages were too annoying.
The problem with using the Python version that's shipped with your OS is that it may contain bugs, or be limited in other ways. If you install Python from Fink or MacPorts, you have the liberty of updating it.
Another, important advantage of managing your own version of Python with a package manager (Fink or MacPorts) is that they help a lot with the compilation of module dependencies (for instance when you use a module that depends on compiled C code). Thus, installing Python modules is certainly easier if you do not use the Python shipped with OS X. This is an important point to consider, before making your choice.
What you do on your on machine is totally up to you. If you're going to deploy your code to other people's, I'd say it's clearly preferable to use the shipped version unless you really need the newer version.
I'm digging up this old topic.
There are no real answers to create your own python distro/framework from source and bundle and package it in a correct way. I tried to compile it from source, linking it against my C programmed application which uses python 3 and works on my computer. But when I move it around the filesystem (e.g to /tmp) it has hardcoded paths in the python compile. And I have no clue what script/wrapper to make.
My point to ship our own python distro is to make sure there is no oddness in interpeter change involved when shipping the application and rely on the OS python install.
It is also nowhere documented on the python docs.
I already found this post 4206511
Various software installations on my laptop each require their own particular version of Python. ViewVC requires Python 2.5 and Blender requires Python 2.6. Mercurial (thankfully) comes with its Python interpreter packaged in a DLL in the Mercurial installation itself.
How do I get by without having to install the entire Python environment each time? Is there some minimal installer which will install the bare minimum without affecting other programs? Can I modify the Blender and ViewVC installations so that they too use their own Python-in-a-DLL?
It's hard to know which "bare minimum" the Blender scripts you'll want to use in the future may be counting on (short of the full Python standard library, which isn't all that large in term of disk space after all). Why not install both Python 2.5 and 2.6? They can coexist nicely (if your scriptable apps use hashbangs like #!/usr/bin/env python instead of specifically mentioning python2.5 or python2.6, you may need to trick out their PATHs just a little bit).
You should be able to get away with installing the Python binaries in the same tree as the specific application I believe (Totally untested hunch though).