I have a software that is mostly written in Python and, for now, I'm using PyInstaller to bundle and distribute the software in a user-friendly way (it's part of my CI pipeline, for Linux and Windows).
However, my performance is terrible and I want to rewrite some heavy parts in Julia while keeping the front-end in Python. I can use PyJulia to do this, but it means that the user has to install Julia manually in order to use my program.
Julia does have the equivalent of PyInstaller, which is PackageCompiler.jl, but I don't know how to call something compiled with PackageCompiler.jl from the Python side.
How can I make this work, so I can bundle and distribute an executable that has Python, Julia and everything it needs to run?
A little more details
My end user is someone (chemists and pharmacists) that have no idea what programming is. They don't have Python, Julia or Docker (and they don't even want to install it).
In my current approach, the software bundled with PyInstaller consists of a single executable with everything inside it (Python and everything it needs). What I really want is to keep the same user experience, but also with Julia running on the backstage.
I'll implement several functions in the Julia side, and I want (almost) the same level of integration as I get with PyJulia.
Maybe I'll go to Rust and just use the C interface, but I really would like to use Julia.
Thank y'all for your time.
Per here: https://julialang.github.io/PackageCompiler.jl/stable/apps.html#Creating-an-app-1 you can get what is basically an executable file and then you can just follow this post: Python Script execute commands in Terminal to execute the file you create.
You could try using JuliaWin. This provides a standalone Julia runtime that works fully self-contained.
We deployed a tool using PyInstaller with the JuliaWin included as one of the datas as PyInstaller calls them. Iirc it was not PyJulia but JuliaCall+PythonCall doing the interfacing in our case.
Unfortunately the startup was ridiculous (order of minutes). This is in part due to Julia's startup time, but largely due to the generated .exe first having to unpack the JuliaWin. So we are currently investigating using PackageCompiler, possibly also switching to providing the user with 2 files instead of 1.
Related
I have been searching for an answer for quite some time and I cannot figure out a robust solution: I have a C# application (on Unity) which needs to call some python functions and libraries. In particular, the python code needs to read a very large tabular file from C# -the equivalent of a large pandas dataframe-, avoiding writing and reading through a file if possible, because given the size it would reduce the performance.
I am a total beginner to C#/Unity, and I have given a look at the following workarounds:
IronPython: it is not an option because the last stable version is for python 2.7. My requirements are python 3.6 and higher, moving towards 3.8.
PyInstaller: it creates .exe files and not .dll. Moreover, it is not clear to me how you could call the executable from C# and pass a dataframe/2D array without writing it on disk. I am also not sure whether it can be called passing an entire input file as argument, if you really want to communicate via files.
Communication via socket: I am a bit lost about it. If this is really feasible on both python and Unity sides, I am happy to see your tutorials -especially for Unity!
Unity Python script editor: it works fine in dev mode. However, the python scripts cannot be included in the build. This: https://forum.unity.com/threads/python-for-unity-editor-only.914843/#post-8330904 seems very suboptimal for a stable build.
Thank you for any hint!
I need to integrate a body of Python code into an existing OSGi (Apache Felix) deployment.
I assume, or at least hope, that packages exist to help with this effort.
If it helps, the Python code is still relatively new and small, so can probably re re-architected to meet whatever constraints are needed. However, it must remain in Python, because of dependencies on third-party libraries.
What are suggested best practices?
The trick is to make this an extender, see 1 and 2. You want your Python code to be separate from the code that handles the interaction with the interpreter. So what you do is wrap the Python code and any native libraries in a bundle. This is trivial since it is just a zip file.
You then develop a bundle that listens to starting bundle (see the BundleTracker) that have python code. A manifest is often used but you can also look in a directory in the JAR. If you detect this code, you extract any native libraries and run the code in the interpeter of your choice.
If can use JYthon then that would be highly recommended. You can then carry the interpreter as an OSGi bundle that runs on the VM. If you need to use a native compiler your life is less rosy. You can rely on the environment to provide you with an interpreter but then why use OSGi in the first place. You basically lose the write once run anywhere advantage. You could go the full monty by creating bundles that contain Python installers for all platforms you support. Can be done, not even that hard, but a maintenance nightmare. Believe me, native code suck, it only does it a bit faster than Java.
I have written a program. I don't know if it is important how it is written but you can find it here: http://pastebin.com/Z3ZvVPV8 Basically, it asks you to assign values to variables and will perform calculations depending on what variables you chose, and prints the answer.
I would like to know how I can make the program run in a window other than cmd (I am using Windows Vista 32bit). I don't need much at all in terms of GUI, just a window that is a bit more user friendly/easier to look at when they are using the program.
EDIT: To those suggesting using IDLE, while that would work for me, if others want to use the program they would have to download it, so I was hoping for a way for that not to happen.
Python comes with a sort of default GUI package TkInter you can use it.
Also there is a lot of other GUI packages available.
The Python standard library offers a lot of ways to implemt simple (but also rather complex) GUIs. I'd like to point you at the documentation of TK (tool kit for graphical interfaces) http://docs.python.org/library/tk.html where you will find also some useful example of use.
Py2Exe is a viable option if you really don't need a gui. This will make it run and look like a command prompt, but it will be an .exe file. Here is a quick quote from thier page: "py2exe is a Python Distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation."
Another alternative is to get Portable Python. Here is a quote from thier webpage: "Portable Python is a Python® programming language preconfigured to run directly from any USB storage device, enabling you to have, at any time, a portable programming environment. Just download it, extract to your portable storage device or hard drive and in 10 minutes you are ready to create your next Python® application." After packaging the portable python and your .py or .pyc file then create a .bat file that runs the portable python "Python-Portable.exe" with the correct command line parameters for loading your script. Be sure to use relative paths in the batch file in case they are running it from a flash drive, or something other than the same location as you.
NOTE: This is really not a good way to do this as thier download page states: "Installed size: based on selected packages, between 49MB and 480MB". Also be sure to read the the current Python Software Foundation License, as that is what Portable Python is released under, and it may or may not be legal to package it in a closed source project. I haven't really looked at the license myself to be able to tell you. If you are releasing it as open source, then there would not be an issue though. As a quick side note, if you need that .bat file to be a .exe file then you can use a .bat to .exe converter battoexe.com is one. This is really going the long way about doing the whole thing, but it is an option.
Sources:
Working with Python on and off for 7 years now, a lot that using a portable version on a flash drive, and also dealing with Batch files much longer.
I have a wxPython application that is almost done & I would like to place it in my portfolio. I have to consider when someone attempts to run my app that they may not have Python, or wxPython, so if they just click the main script/python file its not going to run, right?
How should I distribute my app (how do you distribute ur apps) so that it can be run & also so that it could be run on the 3 major OS's (Unix, Windows, MacOSX)?
I know of py2exe for releasing under windows, but what can I use for Unix & MacOSX to compile the program? Whats the easiest way?
Use Gui2exe and compress with UPX to get unpacked size down.
For a setup file(exe) with uinstall info Inno-Setup is good.
I have use this with wxpython several times and got it to work on all windows versions.
For Gui2exe use optimize(2) - compressed(2) - Bundle files(3)
Bundle files(3) is the most stable,
Bundle files(1) make one big exe-file.
For one exe-file is better as last step to use Inno-Setup
You can use py2exe for Windows and py2app for Mac. PyInstaller works for Windows and Linux. Personally, I use GUI2Exe, which wraps all three and makes them a little easier to use. Note: I don't have a Mac, so I haven't tried it with that. You can check out my series on freezing Python here:
http://www.blog.pythonlibrary.org/2010/08/10/a-pyinstaller-tutorial-build-a-binary-series/
http://www.blog.pythonlibrary.org/2010/07/31/a-py2exe-tutorial-build-a-binary-series/
http://www.blog.pythonlibrary.org/2010/08/31/another-gui2exe-tutorial-build-a-binary-series/
There are a couple others on the blog too.
I suggest both, script for all platforms and frozen binary for lazy windows users.
To answer your latest question, you don't compile python. Python is an interpreted language, it gets compiled on the fly when run. A python frozen binary is actually the python interpreter with your script hardcoded in it. And frozen binaries are windows-only, AFAIK. Besides, Unix and MacOS (usually) come with python pre-installed.
Although I found many answers and discussions about this question, I am unable to find a solution particular to my situation. Here it is:
I have a main program written in FORTRAN.
I have been given a set of python scripts that are very useful.
My goal is to access these python scripts from my main FORTRAN program. Currently, I simply call the scripts from FORTRAN as such:
CALL SYSTEM ('python pyexample.py')
Data is read from .dat files and written to .dat files. This is how the python scripts and the main FORTRAN program communicate to each other.
I am currently running my code on my local machine. I have python installed with numpy, scipy, etc.
My problem:
The code needs to run on a remote server. For strictly FORTRAN code, I compile the code locally and send the executable to the server where it waits in a queue. However, the server does not have python installed. The server is being used as a number crunching station between universities and industry. Installing python along with the necessary modules on the server is not an option. This means that my “CALL SYSTEM ('python pyexample.py')” strategy no longer works.
Solution?:
I found some information on a couple of things in thread Is it feasible to compile Python to machine code?
Shedskin, Psyco, Cython, Pypy, Cpython API
These “modules”(? Not sure if that's what to call them) seem to compile python script to C code or C++. Apparently not all python features can be translated to C. As well, some of these appear to be experimental. Is it possible to compile my python scripts with my FORTRAN code? There exists f2py which converts FORTRAN code to python, but it doesn't work the other way around.
Any help would be greatly appreciated. Thank you for your time.
Vincent
PS: I'm using python 2.6 on Ubuntu
One way or another, you'll need to get the Python runtime on your server, otherwise it won't be possible to execute Python bytecode. Ignacio is on the right track with suggesting invoking libpython directly, but due to Fortran's parameter-passing conventions, it will be a lot easier for you to write a C wrapper to handle the interface between Fortran and the CPython embedding API.
Unfortunately, you're doing this the hard way -- it's a lot easier to write a Python program that can call Fortran subroutines than the other way around.
You don't want any of those. What you should do is use FORTRAN's FFI to talk with libpython and frob its API.