I would like to distribute an application written in python as a .exe file. I have already been able to do this using py2exe, but now I have incorporated the veusz library into my code. Ideally my program should open up a veusz plot (as it does on my computer, which has python, numpy, etc. all installed). However, I want to distribute an executable that does this without having to install python.
When I try running my setup.py with py2exe, everything goes fine and the exe is built. However, once the application runs and gets to the point where it is to display the graph, it sends up:
Runtime error: Unable to find veusz executable on system path.
Can I fix this without having to install a bunch of stuff on my clients' computers? Is this possible? And if I must install something, what is the minimum amount of software I need to install?
Veusz runs its user interface in a separate python process so that it does not block python. If you look at veusz/embed.py, it tries to start up python or a veusz executable. You'd need to modify embed.py to start your .exe (sys.executable) if frozen instead of veusz and pass some special parameter which your program would interpret to start running veusz.embed_remote.runremote.
The python multiprocessing module has to do something similar - you need to call a multiprocess function which checks whether the program was starting by multiprocessing - to get around the fact that Windows doesn't have a working fork.
Related
I compiled a python program using PyInstaller. But when I execute the .exe file on a client, two instances of the .exe is running on the task manager.
How can i eliminate the other .exe?
This question didn't have any clear answer.
I'm using python 2.7 and I'm running the .exe on Windows XP.
I recommend reading this section:
https://pythonhosted.org/PyInstaller/#id74
Bootloader
The bootloader prepares everything for running Python code. It begins the setup and then returns itself in another process. This approach of using two processes allows a lot of flexibility and is used in all bundles except one-folder mode in Windows. So do not be surprised if you will see your bundled app as two processes in your system task manager.
In general I'm curious, does using a utility that converts a non-exe to an exe increase speed? It's my understanding that they just package the interpreter inside the exe.
In specific, if you have a python script and use py2exe on it, does the resulting executable run faster than the .py? My boss seems to have the assumption it does but I'm not so sure.
Especially when dealing with multiple modules. For example say you have modules first.py and second.py. You compile them all to executables. When they were .py they second.py could be called as
from second import main
main()
Now that they're executables you have to start a new process, which surely is slower?
subproccess.call(["second.exe"], shell=True)
Do I understand this correctly? Or does importing from another python module actually start a new instance of the python interpreter or something?
In our case the target platform is always Windows.
Your boss is misinformed. All py2exe does is package your program into a self-contained package capable of running without dependencies. It is still the same bytecode running on the same interpreter (well, whatever one is packaged).
See this other answer for about all of the "optimization" you can get out of using -o flags.
Also, yes, definitely run some benchmarks to confirm for yourself.
The original goal was to write a software executable on Windows platform that could read numbers from 7-segment displays and record it at a constant time interval. I tried out a couple of OCR libraries in Python (since I was planning to write the program in Python) but learned that they are more suitable for handwritten letters and soon redirected my attention to another open source program written in C, specifically designed for reading numbers from 7-segment displays: http://www.unix-ag.uni-kl.de/~auerswal/ssocr/
So I compiled the source code in Linux and planned to move the compiled file, along with its linked library files, to the Windows machine, naively believing that I could simply "exec" from a Python script to execute the program. It turns out it couldn't - just trying to run the program (after manually adding an .exe extension at the end and double clicking) generates a response "the app cannot run on this pc. to find a version for this computer, check with the software publisher".
So my question is, whether there is a way to simply execute the C program from a script on Windows platform, and if not, what you might suggest me do to complete the aforementioned task?
You can execute any program using Python (like other programming languages). But what happens (for all languages) is that they do a system call and ask the underlying operating system to execute the program, because that is one of the responsibilities of the OS.
Open a Python REPL (or write a Python script) and try this (This is only one of the ways to execute a program from python)
import subprocess
# if you're on windows call this
subprocess.call("notepad", shell=True)
# If on Linux call this
subprocess.call("ls", shell=True)
What happens is that Python asks OS to execute the specified program (notepad or ls), weather OS can run the requested application is another story.
Your C program is compiled on Linux so it is an executable in a format that Linux can run (probably ELF format). Windows requires executable files to be in a different file format. File extensions just help the environment to treat files appropriately. If you change the extension of your Linux executable to '.exe', it does not change its content, so Windows still would not be able to run it.
You need to recompile your C program on Windows so the compiled program is executable on Windows. If the program requires a POSIX environment (for example if it uses fork() syscalls or etc.), then you could use Cygwin on Windows (that provides system calls and libraries available in Linux for Windows) to compile it.
There was a simple task - well, in Python it took around one hundred lines of code (the task was only to ask users for input files, process them and write results on disk). But the requirement was that it must be executable on PCs without Python interpreter. I used py2exe to make an executable file (it has increased the size from 3Kb to ~12 Mb but doesn't really matter).
The problem is - when one tries to run this *.exe, it shows black command line window for half a minute and only after that - file-selecting dialogue. Is there a possibility to get rid of that half-minute delay? Of maybe there are other .py to .exe converters which would suit better in this situation?
In py2exe
console = ['yourscript.py']
will generate a command window, use the following instead
windows = ['yourscript.py']
http://www.py2exe.org/index.cgi/ListOfOptions
This is perfectly normal when making exe files with Python code. When you make an executable file, Python itself is bundled into the .exe. This is so the user does not have to install Python on their machine to make it work. Python is an interpreted language and requires the interpreter to be bundled.
You could always try using alternatives to see if the compression rate is smaller, but chances are, its not a big deal.
If it is the code that is taking a long time, you may consider posting your code on Stack Exchanges' Code Review to see if there is anything that could be improved.
Further, if you are using Python 2.7, you should consider checking out PyInstaller. It is surprisingly easy, however, it has a couple of problems - especially with the PySide Framework - works great for plain PyQt though.
pyinstaller myscript.py --name="MyApp" --onefile
However, for a full list of optional parameters you should really check out the documentation.
I'm currently working on a small python script, for controlling my home PC (really just a hobby project - nothing serious).
Inside the script, there is two threads running at the same time using thread (might start using threading instead) like this:
thread.start_new_thread( Function, (Args) )
Its works as intended when testing the script... but after compiling the code using Pyinstaller there are two processes (One for each thread - I think).
How do I fix this?
Just kill the loader from the main program if it really bothers you. Here's one way to do it.
import os
import win32com.client
proc_name = 'MyProgram.exe'
my_pid = os.getpid()
wmi = win32com.client.GetObject('winmgmts:')
all_procs = wmi.InstancesOf('Win32_Process')
for proc in all_procs:
if proc.Properties_("Name").Value == proc_name:
proc_pid = proc.Properties_("ProcessID").Value
if proc_pid != my_pid:
print "killed my loader %s\n" % (proc_pid)
os.kill(proc_pid, 9)
Python code does not need to be "compiled with pyinstaller"
Products like "Pyinstaller" or "py2exe" are usefull to create a single executable file that you can distribute to third parties, or relocate inside your computer without worrying about the Python instalation - however, they don add "speed" nor is the resulting binary file any more "finished" than your original .py (or .pyw on Windows) file.
What these products do is to create another copy of the Python itnrepreter, alogn with all the modules your porgram use, and pack them inside a single file. It is likely the Pyinstaller keep a second process running to check things on the main script (like launching it, maybe there are options on it to keep the script running and so on). This is not part of a standard Python program.
It is not likely Pyinstaller splits the threads into 2 separate proccess as that would cause compatibility problems - thread run on the same process and can transparently access the same data structures.
How a "canonical" Python program runs: the main process, seen by the O.S. is the Python binary (Python.exe on Windows) - it finds the Python script it was called for - if there is a ".pyc" file for it, that is loaded - else, it loads your ".py" file and compiles that to Python byte code (not to windwos executable). This compilation is authomatic and transparent to people running the program. It is analogous to a Java compile from a .java file to a .class - but there is no explicit step needed by the programmer or user - it is made in place - and other factors control wether Python will store the resulting bytecode as .pyc file or not.
To sum up: there is no performance impact in running the ".py" script directly instead of generating an .exe file with Pyinstaller or other product. You have a disk-space usage inpact if you do, though, as you will have one copy of the Python interpreter and libraries for each of your scripts.
The URL pointeded by Janne Karila on the comment nails it - its even worse than I thought:
in order to run yioru script, pyinstaller unpacks Python DLLs and modules in a temporary directory. The time and system resources needed todo that, compared with a single script run is non-trivial.
http://www.pyinstaller.org/export/v2.0/project/doc/Manual.html?format=raw#how-one-file-mode-works