I'm trying to write an application that should work both on Windows 98 and XP. I decided to go with Python, but I'm having trouble even installing it on Win'98 (Python 2.7 installer says something about missing features of Windows Installer, but AFAIK 2.0 is the latest Windows Installer version compatible with '98).
Does anyone have a working Windows 98 environment with Python and wxPython? How did you make it work? I don't need Python 2.7, but a 2.4 or 2.5 would be nice.
If not, what other high-level language would you suggest that is actively maintained, can display Windows widgets and works with Windows 98? (asm/C/C++ and other low-level languages are out of question -- this is a simple application whose main job is to display windows and dialogs).
I'm pretty sure we used Python2.4 and wxPython on '98 way back when.
I don't have a win98 machine to test it on, but it looks like at least Python2.5.4 binaries are available for win98
I think win98 support may have been dropped for 2.6
wxPython download page says this
Microsoft Windows
The Win32 version of wxPython is
distributed as a set of standard
self-installing executables. This
allows you the convenience of using
the Start Menu and Add/Remove Programs
just like any other Windows software.
There are two versions of wxPython for
each of the supported Python versions
on Win32. They are nearly identical,
except one of them has been compiled
with support for the Unicode version
of the platform APIs. Unless you've
been told differently, you probably
want to get the Unicode build of
wxPython. Although they are not
nativly Unicode like NT-based systems,
the Unicode build of wxPython will
also mostly work on Windows 98/Me
systems using a Microsoft hack called
MSLU (or unicows.dll) that translates
unicode API calls to ansi API calls.
However the coverage of the API is not
complete so there are some difficult
bugs lurking in there, so the best
thing to do is to upgrade your
machines if possible, otherwise
Windows 98/Me users may want to try
the ANSI build instead.
and they are still release installers for Python2.5
Yes, Python droped Win9x/NT support at version 2.5.4.
However there are alternates builds: http://www.msfn.org/board/topic/162317-python-27-for-windows-95/
Related
I am using Xcode to build a PyObjC application. The app runs fine on the build machine (running 10.8) but crashes on startup on a machine running 10.6, because it fails to find the Python 2.7 installation. Fair enough -- the preinstalled Python on 10.6 is Python 2.5. But I don't really care which Python version my app uses, I just want it to use the latest version of Python it can find.
How can I either:
A) Tell my app to use the latest version of Python available on the host system, OR
B) Bundle the entire Python source into my app?
I have been very frustrated by this issue and any help would be greatly appreciated!
Good question. I wrestled with this for an embedding problem a few years ago and ended up dynamically linking against a specific version that I knew was available on every platform.
I had assumed originally that the Python.framework's Current would be adequate, but it seems to get resolved at link time by Xcode, therefore making the link specific to a particular version. For my purposes, I was able to link directly to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/Python
Which works for OS X 10.7 and 10.8. If you need to go back to 10.6, you'll want to try linking to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Python.framework/Versions/2.5/Python
Obviously, if you're compiling against the 10.6 SDK, you'll want to use that, but the key is to make sure that you link to a version-specific version of the libraries and not the framework version itself. You should be able to manually navigate to the specific version through the + button in the Link Binary with Libraries, but if you have problems, you can open the Python.framework from the SDK directly in the Finder and drag the version-specific library into the Link Binary with Libraries group.
If you find a way around this, then please post another answer here, but this was effective for me to link for embedding into my app.
Use py2app to create the application bundle, and do that using a separate install of Python (that is don't use /System/Library/Framework/Python.framework). The python install you use should be compiled with the MACOSX_DEPLOYMENT_TARGET set to the minimum OSX release you want to support.
When you do this, it should be possible to deploy to older OSX releases. I regularly do this for building apps on a 10.8 machine that get deployed to a 10.5 machine.
You do need to take some care when including other libraries, especially when those include a configure script: sometimes the configure script detects functionality that is available on the build machine, but not on the deployment machine.
BTW. You need to link against the same version of Python as you use at runtime. CPython's ABI is not compatible between feature releases (that is, the 2.6 ABI is not necessarily compatible with the 2.7 ABI). For python 3.x there is a stable ABI that is compatible between feature releases, but AFAIK that's primarily targeting Python extensions and I don't know how useful that is for embedding Python in your application.
I'm writing a program in python using PySide(PyQt) and I want to distribute it to friends and family when I'm finished. I have looked at other posts in stack overflow, but I can't seem to find any good ones showing an easy solution(command line or otherwise) that will create an executable for my program to be run on other computers who don't have python or Qt etc. I'm running Ubuntu right now, however I would like to be able to package for windows as well.
Edit: I wrote all the Qt interface in my python script, so the whole project is contained in the one script.
I have used PyInstaller to create executables for scripts using PyQt4 under Windows without any trouble. Though I have not used it on Linux, it claims Linux (and OSX) support as well. You may need to create your Windows binaries in a Windows system or through Wine according to the FAQ:
Can I package Windows binaries while running under Linux?
No, this
is not supported. Please use Wine for this, PyInstaller runs fine in
Wine. You may also want to have a look at this thread in the
mailinglist. In version 1.4 we had build in some support for this, but
it showed to work only half. It would require some Windows system on
another partition and would only work for pure Python programs. As
soon as you want a decent GUI (gtk, qt, wx), you would need to install
Windows libraries anyhow. So it's much easier to just use Wine.
Is there a Mac alternative to the Windows Python extension, pyHook? I need to catch keystrokes outside of the python app; In any other software.
I've googled like hell an haven't found anything.
Cheers.
Short answer, No
This extenstion was designed specifically for windows
System Requirements
Windows 2000 or later (low-level hooks are not supported in earlier versions of Windows)
Python 2.4 or later
PyWin32 (formerly known as win32all extensions)
Source: http://sourceforge.net/apps/mediawiki/pyhook/index.php?title=Main_Page
I have a lovely Macbook now, and I'm enjoying coding on the move. I'm also enjoying coding in Python. However, I'd like to distribute the end result to friends using Windows, as an executable.
I know that Py2Exe does this, but I don't know how portable Python is across operating systems. Can anyone offer any advice? I'm using PyGame too.
Many thanks
The Python scripts are reasonably portable, as long as the interpreter and relevant libraries are installed. Generated .exe and .app files are not.
Py2exe generates Windows executables, so they will only work on the Windows Platform. The FAQ at http://www.py2exe.org/index.cgi/FAQ has more information on how it all works. Essentially it provides what is needed to run on Win9x as well as more current platforms. NOTE: the FAQ mentions some potential gotchas with character encodings and the work arounds.
With python, it is common enough on Unix based systems, as several Linux distributions have their custom maintenance scripts written in the language. So the Python scripts will be just as portable as Ruby scripts, etc. As long as the target machine has the interpreter and you are not using external programs that are only on one type of platform, others will be able to use your work.
Personally I experienced huge difficult with all the Exe builder, py2exe , cx_freeze etc. Bugs and errors all the time , keep displaying an issue with atexit module.
I find just by including the python distro way more convinient. There is one more advantage beside ease of use.
Each time you build an EXE for a python app, what you essential do is include the core of the python installation but only with the modules your app is using. But even in that case your app may increase from a mere few Kbs that the a python module is to more than 15 mbs because of the inclusion of python installation.
Of course installing the whole python will take more space but each time you send your python apps they will be only few kbs long. Plus you want have to go to the hussle of bundling the exe each time you change even a coma to your python app. Or I think you do , I dont know if just replacing the py module can help you avoid this.
In any case installing python and pygame is as easy as installing any other application in windows. In linux via synaptic is also extremly easy.
MACOS is abit tricky though. MACOS already come with python pre installed, Snow leopard has 2.6.1 python installed. However if you app is using a python later than that and include the install of python with your app, you will have to instruct the user to set via "GET INFO -> open with" the python launcher app which is responsible for launcing python apps to use your version of python and not the onboard default 2.6.1 version, Its not difficult and it only takes a few seconds, even a clueless user can do this.
Python is extremely portable, python pygame apps cannot only run unchanged to the three major platform , Windows , MACOS ,Linux . They can even run on mobile and portable devices as well. If you need to build app that runs across platform , python is dead easy and highly recomended.
If you are planning to include Linux in your portability criteria, it's worth remembering that many distributions still package 2.6 (or even 2.5), and will probably be a version behind in the 3.x series as well (I'm assuming your using 2.x given the PyGame requirement though).
Versions of PyGame seem to vary quite heavily between distros as well.
If I create a gui for windows using python 2.6 and Qt, and then want to running in solaris or linux world.
What do I need on both systems, I'm guessing 2.6 and Qt for both platforms.
Is this correct or would there be a better solution.
If wxpython, the same right?
To run a Python application, one obviously need to have the Python interpreter installed, usually at least the same version used for developement (but sometimes you didn't use features new to that version, so the code is backwards-compatible). A newer version should work, too - only Python 3 isn't backwards compatible to 2.x versions.
Also, all third party libraries need to be installed, of course. So if your GUI uses PyQt, users need PyQt installed. If you use wxPython, users need wxPython installed.
Apart from that, it is possible, although much harder than with certain other languages, to break compability with other platforms, especially when dealing with files and paths manually (e.g. joining an absolute with a relative path with "\\" instead of using the cross-platform os.path.join).
It is possible (and especially for applications aimed at casual users, especially on Windows) to "freeze" a Python program and libraries it uses into an executable file (ideally without dependencies, I don't know if that's always the case in practice). There are a few tools that work for one platform, and the supposedly cross-platform cx_Freeze. Although I don't know if one can produce a Linux executable on a windows machine...