I am currently starting a business where I will be providing support to clients directly on their business offices. I need to be able to go to different computers and be able to run custom python scripts, my question is if there's a way to make my python environment portable?
Assuming that your users are running Windows, I see two options here.
If you have already defined which scripts you will be running, compile them into exe files using py2exe, that way you can just plug a USB and run them as needed. (the caveat is that some antivirus will automatically block the unsigned executables)
The other option is to use WinPython, that is a full python environment with a lot of packages already preinstalled that ives in it's own directory. In case you need to install a new package, just use the Powershell or CMD that comes with it and use the preinstalled "pip".
I found something interesting here Portable Python. I use that method to create portable Python 3.9 and 3.10 and everything works so have a look.
Related
I need to package my Python application, its dependencies, and Python itself into a single MSI installer for distribution to users. The end result should desirably be:
Python is installed in the standard location
the package and its dependencies are installed in a separate directory (possibly site-packages)
the installation directory should contain the Python uncompressed and a standalone executable is not required
Kind of a dup of this question about how to make a python into an executable.
It boils down to:
py2exe on windows, Freeze on Linux, and
py2app on Mac.
I use PyInstaller (the svn version) to create a stand-alone version of my program that includes Python and all the dependencies. It takes a little fiddling to get it to work right and include everything (as does py2exe and other similar programs, see this question), but then it works very well.
You then need to create an installer. NSIS Works great for that and is free, but it creates .exe files not .msi. If .msi is not necessary, I highly recommend it. Otherwise check out the answers to this question for other options.
My company uses the free InnoSetup tool. It is a moderately complex program that has tons of flexibility for building installers for windows. I believe that it creates .exe and not .msi files, however. InnoSetup is not python specific but we have created an installer for one of our products that installs python along with dependencies to locations specified by the user at install time.
I've had much better results with dependencies and custom folder structures using pyinstaller, and it lets you find and specify hidden imports and hooks for larger dependencies like numpy and scipy. Also a PITA, though.
py2exe will make windows executables with python bundled in.
py2exe is the best way to do this. It's a bit of a PITA to use, but the end result works very well.
Ok, I have used py2exe before and it works perfectly except for one thing... It only works on executable windows machines. I then learned about Jython which turn a python script into a .Jar file. Which as you know is executable from any machine that has Java ("To your latest running version") installed. Which is great because both unix, windows, and ios (Most of the time) Run java. That means its executable from all of the following machines. As long as they run Java. No need for "py2mac + py2exe + freeze" just to run on all operating systems. Just Jython
For more information on how it works and how you can use it click here.
http://www.jython.org/
I have a windows 7 computer and was wondering whether to use the windows version of python or the one in cygwin. Especially with regard to modules that do not come pre-installed, which one is easier to install new modules?
ActivePython works just fine on Win7. Cygwin would add an unnecessary layer of complexity.
It really depends on what you want to use it for, far more than which one is easier to install new modules.
If you plan on running scripts from within the cygwin bash shell, or to access files within the cygwin subtree of your directory, to WSGI to a cygwin web server, etc., you probably want the Cygwin version.
If you plan on running scripts from within the cmd.exe DOS prompt, or to access files in special locations under your home directory, or to WSGI to a native web server, you probably want the native version.
If you really do want to know which one is easier to install new modules for… the answer is that it depends.
If you want pre-built binary packages, Cygwin only has a handful of them, while Cristoph Gohkle has a ton of packages for native Python.
If you want to build packages yourself (manually, or just using pip automatically), and you need any packages that use C extension modules, you'll need to set up a compiler, which is a bit easier in Cygwin, but not all that hard in either.
There are a few modules out there that aren't developed or tested for cygwin, and will guess your platform as linux or Windows or something else wrong, or just make inappropriate assumptions.
There are also a few modules that only work on POSIX, that do happen to work with cygwin but not with native Windows.
Both work, it all comes down to which you're more comfortable using; windows or cygwin.
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?
I wrote a program which uses a number of built in modules. The program is meant to be used by different persons on their systems. They dont have enough knowledge in python to install it when their system doesnt have the module needed to run the program. Is there any way of handling that.
Also I want to package the program as an executable in linux. It contains 3 py files and one text file only.
I think what you need is to create a debian package that handles the dependencies and the installation process.
I'm an Ubuntu user but this Complete Ubuntu Packaging Guide should help you get started. Good luck!
You can create an executable that contains your python modules and the python interpreter. You can use PyInstaller for creating such an executable.
I think the easiest way to achieve this on a debian distribution is to package your python application in a debian package. You can use this module to make life easier.
I'm looking for a way to let multiple Python programs coexist on the same Windows machine.
Here's the problem: suppose program A needs Python 2.5, B needs 2.6, C needs 3, and each of them needs its own version of Qt, Wx or whatever other modules or whatever.
Trying to install all these dependencies on the same machine will break things, e.g. you can install different versions of Python side-by-side but only one of them can have the .py file association, so if you give that to Python 2.5 then B and C won't work, etc.
The ideal state of affairs would be if program A could live in C:\A along with its own Python interpreter, Qt/Wx/MySQL driver/whatever and never touch anything outside that directory, ditto for B and C.
Is there any way to accomplish this, other than going the full virtual box route?
edit: I tried the batch file solution, but it doesn't work. That is, it works on simple test scripts but e.g. OpenRPG fails at some point in its loading process if its required version of Python doesn't own the file association.
VirtualEnv.
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.4/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.
See previous answer here.
The other tool you should look at is pip which is great for installing particular versions of a library into a virtual environment. If you need to run v 1.0 of a library in python v 2.x for one application and 1.1 of the same library in python v 2.x, for example, you will need virtualenv plus a means of installing a particular version in that environment. Virtualenv + pip is your best choice.
Use batch files to run scripts, write in notepad for example:
c:\python26\python.exe C:\Script_B\B.py
and save it as runB.bat (or anything .bat). It will run with interpreter in c:\python26\python.exe file specified after a whitespace.
One solution would be to craft a batch file that invokes the correct interpreter for a given application. THis way, you can install additional interpreters in separate folders.
Probably not perfect but it works.
Have you considered compiling them to EXEs? Once you do that, all you have to do is call the EXE, for which the machine does not require python to be installed. All the required modules etc are packaged with the distribution when you compile.
write a python script that mimics the way unix shells handle scirpts -- look at the first line and see if it matches #!(name-of-shell). Then have your python script exec that interpreter and feed it the rest of its arguments.
Then, associate .py with your script.
It looks like the best solution is a batch file that sets the file association before running the appropriate version of Python, as mentioned in the comments to one of the answers here: how to run both python 2.6 and 3.0 on the same windows XP box?