I've been wondering why python gets installed in directory named Frameworks? (though it's not Framework)
$ which python
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
Somebody please explain! Thanks!
That's the way it is in OS X.
The Mac/README file in the Python source tree goes into some more details of the advantages of a framework build versus a traditional UNIX shared-library build, which will also work on OS X. The main points:
"The main reason is because you want
to create GUI programs in Python.
With the exception of
X11/XDarwin-based GUI toolkits all
GUI programs need to be run from a
fullblown MacOSX application (a
".app" bundle).
While it is technically possible to
create a .app without using
frameworks you will have to do the
work yourself if you really want
this.
A second reason for using frameworks
is that they put Python-related items
in only two places:
"/Library/Framework/Python.framework"
and "/Applications/MacPython 2.6".
This simplifies matters for users
installing Python from a binary
distribution if they want to get rid
of it again. Moreover, due to the way
frameworks work a user without admin
privileges can install a binary
distribution in his or her home
directory without recompilation."
Related
I'm working in the VFX industry and we deal with different software packages that ship with their own Python interpreter. We are running on Linux and use modules to handle our environments to make sure that people are using the correct version of all applications depending on the project they are working on.
Since months, we are trying to setup an environment that supports multiple versions of Python. And what is blocking right now are additional Python libraries that we are using in our in-house tools, like sqlalchemy, psycopg2, openpyxl, zmq, etc.
So far, for each project, we have config file that defines the version of each package to be use including the additional Python modules. And to use the correct Python version of each Python module, we look up the main Python interpreter defined in that same modules definition file. This works as long as the major and minor versions of all Python interpreters do line up.
But now, I would like to start an application that ships with a Python 3.7 interpreter and another application with a Python 3.9 interpreter and so on. All applications do you use our in-house tools which need the additional Python modules. Of course, this fails when trying to import any additional module.
For now, the only solution that I see is to install the corresponding Python modules in the 'site-packages' of each application that comes with its own Python interpreter. That should work. But this means that we have to install for each application version all necessary Python modules (ideally, the same version of it to avoid compatibility issues) and when we decide to update one of them, this needs to be done again for all 3rd party applications.
That does not sound super-efficient to me.
Do you have similar experiences and what did you came up with to handle this? I know, that there are more advanced packages like rez to handle complex environment setups, but although I do not know the details of rez, I could imagine that the problems stays the same. I guess that it is not possible to globally populate PYTHONPATH with additional modules so that it works on multiple Python interpreter versions.
Another solution that I could imagine is to make sure that on startup of each application that needs additional Python modules, we do our own sys.path modification depending on the interpreter version. That would imply some coding but we could keep a global version handling without installing them everywhere.
Anyway, if you have any further hints, please let me know.
Greets,
Carlo
I have a python application (3.5) that I’m trying to distribute. It:
Uses no GUI libraries (it runs in the browser)
Uses several external packages (Flask, SocketIO, httplib2)
maintains saved config and data files inside the main source directory
The target users:
Use Mac or Windows
Do not understand the concept of the terminal/command line (testing has shown that it can take hours to teach users how to cd into the source directory to run a .py file).
Generally have little difficulty installing the python interpreter from python.org (but have great trouble starting and exiting the python console).
Are generally of very low technical ability.
Preferably, the app should:
be “click and play”, as I have found that typically the cd navigation is the biggest hurdle preventing users from running my application.
not require manually modifying any system settings
I am developing from Ubuntu Linux. I have access to a Windows VM, but not a Mac computer. How do I distribute my application?
There are a couple of applications that can help you to distribute a Python Application, for this case you want to take a look on Python freezing tools like py2exe (windows only) or py2app (MacOs).
This two will help you distribute your code without all the hassle of making the user to install the dependencies and run anything from the command line.
However if your application runs on the browser, you probably want to just put that into a server (take a look of openshift, it's free) it will make your life a lot easier.
Is there a way to distribute a python library with an application, so that it can be run with out any installation? The app is primarily going to be used in a computer lab, where users do not have permission to install global libraries. Ideally, users would simply be able to unzip a folder and run the app. The following can be assumed:
The python interpreter is present
Linux operating system
The specific library I need is matplotlib, but I would like to find a generic solution. I've looked at programs like PyInstaller, but they create very large programs that are slow to start. They also include a python interpreter, which is unnecessary.
Firstly, p2exe is Windows only.
In principle you can put all of you libraries into the ZIP file so they get expanded in place with thie application. At most you may need to adjust the PYTHONPATH variable to point at the lib's location.
There is no technical difference between modules installed on the path and in the system's python installation.
Have you looked at cxfreeze?
Not sure if this is the location to ask this, so please close or move as appropriate.
We are bundling Python2.7 64-bit and a number of python libraries (GDAL, SciPy, Numpy) into an application (py2app / pyinstaller). I wonder if it is possible to create a stand alone terminal that has access to the installed libraries, but not the system libraries. This would be akin to FWTools.
The goal is to allow the user to open a command prompt within the GUI and have access to all of the libraries within the application a la a virtual environment.
For example, a user with GDAL 1.8 installed could download this application, launch a stand alone command line and utilize our build of gdal 1.9.1 from within the application.
Any references would be appreciated as we are just considering this approach and are unsure of the feasibility.
We are writing this in python.
There isn't a very easy way to embed a console / terminal into any of the GUI frameworks. The closest I've heard of is PyGTK's VteTerminal. You might be able to use Python's curses library, but I haven't been able to find any good ways to wrap that in a GUI either.
If all you want is a Python shell, you might be able to use wxPython's PyShell or PyCrust widgets. Those are pretty straight-forward.
I'm talking about deploying Python-made, GUI-based, desktop applications via .app and .exe format for OSX and Windows. As far as I've gone into Python, I've only seen it as an application that runs on the Terminal / Command Prompt. I know that it is possible to create a user interface for it using various offerings on the internet (wxPython?). I just want to see how it passess off as a way for a developer to create mac and windows applications with as little code difference as possible.
I find that Python is a very good language for GUI programming. As you have stated, you can use the bindings for wxWidgets (wxPython), but there's also a binding for just about every other cross-platform GUI toolkit you can think of (Tk, Qt, GTK, FLTK, etc.). These GUI toolkits should allow you to make a program that will run unmodified on most OSs.
In terms of Python OS compatibility, it will behave virtually the same on all OSs, except for one or two modules such as mmap.
Using py2exe, py2app, or similar tools, you can embed a Python interpreter (along with your program's bytecode and it's dependencies) within an executable, making it easy to distribute an application. An end user can then open the program as they are used to. If you want the "security" of a compiled language, Python will not be the best language for you to use (but I prefer readability over safety :).
Another thing to consider with cross-platformness is what OS specific features you plan on using. Most GUI toolkits will not support things such as Microsoft's DWM (though you can use OS features through ctypes).
I think what you're looking for is PyQT and Tkinter. Both are GUI Libraries for use with Python. Both are cross-platform. Further, for packaging up .exe and .app for distribution, look at py2exe and py2app.
For Windows, the easiest approach is py2exe. There's also a similar project for MacOS. It's called py2app. Most GUI frameworks are cross platform. Just check their documentation, or even the home pages should have it.
Make good use of the os module. It has many function that will handle cross platform situations. A common example is file paths. When you build a path should it be backslash or forward slash? os.path.join handles that for you, and works based on which operating system it's running on. You shouldn't have to modify your code at all when shipping from OS to OS. It should run on Linux just as well, naturally.
By the way, MacOS often comes prepackaged with Python. As long as it's a somewhat recent version this can make the difference between a Hello World script being 1kb and 30mb, so avoid packaging Python with it. Unfortunately Windows isn't as well equip. Consider an option for "I already have Python installed" when downloading the exe.