When you write an application using Qt, can it just be run right away in different operating systems? And (correct me if I'm wrong) you don't need to have Qt already installed in all of the different platforms where you want to execute your application?
How exactly does this work? Does Qt compile to the desired platform, or does it bundle some "dlls" (libs), or how does it do it? Is it different from programming a Java application, that runs cross-platform.
If you use Python to write a Qt application with Python bindings, does your end user need to have Python installed?
Qt (ideally) provides source compatibility, not binary compatibility. You still have to compile the application separately for each platform, and use the appropriate dynamic Qt libraries (which also need to be compiled separately, and have some platform-specific code).
For your final question, the user would need Python, the Qt libraries, and the binding library (e.g. pyqt), but there are various ways to bundle these.
PyQT [and its open source cousin PySide] are a great cross-platform QT binding for python, but it is not a magic solution for shipping your application for all platforms without doing any packaging/installer maintenance. I think maybe you might be expecting some magic.
QT is a cross-platform library written in C++. That means, you can write your C++ or Python (or other language with bindings) code once, and create a "window" (a form, a dialog box, something on the screen) and populate it with controls (buttons, and all that) and not have to deal with the platform differences in how buttons are made in Windows, Linux, and on Mac OS X.
Because it is a library, it can be packaged in multiple ways. It can be "statically linked" (built into your executable/binary/app) or "dynamically linked" (known as a DLL in windows, a shared library or on unix/linux or as a framework, in mac os x). It is not always "installed" on a computer, unless it is a shared library.
Even when it is "installed" onto a computer, multiple versions might exist on that computer, and so it is not proper to think of it as being an extension to your computer, but rather an extension to an application (a program) on your computer.
If you use Python bindings for QT, then your installation package for your application needs to include the QT binding's binary files (python extensions), the basic Python runtime environment including the Python executable and basic libraries, and your program's source code. It is possible to package most of this up into a single "bundle". On Mac OS X, for instance, all this can easily be put into a an ".app" bundle, and on Windows, and Linux, I believe there are packaging and installation tools that can help you do this easily.
Even though you will only need to write the user interface code for your application once, you will not magically get the ability to ship an application on all three primary platforms at once, without doing at least the building of the installer or packaging, separately for each platform. Users expect to download a setup/install package for Windows or Mac OS X, and perhaps for Unix/Linux it depends further on which distribution you install.
Update thanks to AdamW for this nokia link providing deployment information
The problem is your definition of "installed". For Qt to work, the executable just has to have access to the proper libraries.
Of course that for each platform a different executable and libraries have to be produced (see Qt docs).
About Python, if you are to run a Python executable you have to have it installed (in a more traditional kind of way). Unless you are running with py2exe in Windows, for instance.
Related
I have a C++ application that uses machine learning from Python and my current approach is making a single file executable with pyInstaller and then just running it from C++. This have obvious drawbacks, notably interapplication communication. At the moment I'm using an intermediate JSON file to talk to each other but this is massively suboptimal for my future requirements. What's beautiful about this, is that is working on all major platforms without too much hassle.
Section 1.6. from Python's manual reads "Compiling and Linking under Unix-like systems"
Does this mean that Python interpreter will be inside my application binary and target system doesn't need to have Python installed as the program will always use embedded interpreter ? If so, whats with python libraries ? Can I embed a whole conda enviroment ?
Also, whats with:
"(...) under Unix-like systems"
Does this means this approach is not multiplatform ?
Thanks in advance.
Embedding the Python interpreter is possible on all platforms. However it will only be the interpreter. Embedding any libraries will be a lot harder or even impossible.
But since you seem to deploy the Python libs already, you can use them just fine from the embedded interpreter. And then you could bridge C++ and Python without IPC, since they are both running in the same process.
pybind11 is very nice for embedding and generating C++ <-> Python interfaces.
A possible alternative, depending on the libraries in use, may be to export the model and use a C++ library to load and use it (for instance Tensorflow -> ONNX -> ONNX runtime).
It means that cpython (Python interpreter) will be inside your application. You will be able to run Python code and observe and manipulate virtual machine state directly from C++ code (good entry point C API reference is here). Your application might have some additional dynamic library dependencies (which ones depends on compilation options of embedded Python). Also interpreter isn't completely self contained and depends on some external .py modules normally shipped with Python distribution (as standard library). If you plan to import external modules that expect standard library, you will have to ship it with your application. There are ways how to build modules into binary too (freeze) but you might run into issues specially with modules that rely on filesystem.
As far as I tried, this procedure works on UNIX like systems and Windows (where easiest way is to link against DLL which you then ship with your application). On Windows you also need to make sure that you compile with same compiler as was used to compile DLL (or you compile Python DLL from source). Here is additional information about embedding on Windows: https://docs.python.org/3/faq/windows.html#how-can-i-embed-python-into-a-windows-application
Just note that embedding Python and shipping 3rd party modules with your application might have some licensing consequences.
I've found several answers for this subject on stackoverflow but I'd like to reiterate.
I created a small gui application in python that uses Tkinter (if that matters), uses icons and separate text files with configuration rules and other resources.
So basically, there is one executable .py script, a bunch of text files and gif icons.
I need to create an installer for windows. I have never tried to make an installer before, but considering using NSIS.
What installer serves best for such setup?
I want to make an installation file for my python source code"
You have to use NSIS, InnoSetup, BitRock Installer, IzPack or equivalent to produce a platform installer. So you have to take the binary result produced on the first part and package it for os distribution. Almost all the installer systems are thinked for Windows systems. Cross platform : Zero Install, IzPack ... If you use IzPack you can have a cross platform installer paying the price of including a jvm.
And i Believe This >> HELP Can be Light of Your Way ;)
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.
I'm looking for some information about the roll-out of a python project that uses several external libraries wrapped for python. Are there tools for this? What kind of external files do I need to use my project on anonther PC? Dlls? .pyd? What else? What to do with user- and pythonpath?
Background: I'm working on a C++ application with some other developers. To learn some python and because of some other reasons, I also build the functionality of this C++ app into a python app that does the same things the way I would like them to work. Several libs are used, QT (via PyQt4), VTK, and some more.
So what would I need to do to use my python program on another computer which the least amout of work for the other computers user?
The answer is highly dependent on what libraries you are using, how they are installed, which platforms you will deploy to etc.
Take a look at
Pip (dependency handling, installation)
Virtualenv (python environment sandboxing)
Fabric (automation)
Here's what I want:
Given a set of definitions (preferably in Python) on what files to install where and what post-install script to run, etc.. I would like this program to generate installers for the three major platforms:
MSI on Windows
dmg on MacOSX
Tarball w/ install.sh (and rpm/deb, if possible) on Linux
For example,
installconfig.py:
name = 'Foo'
version = '1.0'
components = {
'core': {'recursive-include': 'image/'
'target_dir': '$APPDIR'}
'plugins': {'recursive-include': 'contrib/plugins',
'target_dir': '$APPDIR/plugins'}
}
def post_install():
...
And I want this program to generate Foo-1.0.x86.msi, Foo-1.0.universal.dmg and Foo-1.0-linux-x86.tar.gz.
You get the idea. Does such a program exist? (It could, under the hood, make use of WiX on Windows).
NOTE 1: Foo can be an application written in any programming language. That should not matter.
NOTE 2: Platform-specific things should be possible. For example, I should be able to specify merge modules on Windows.
Look into CPack. It works very well with CMake, if you use that for your build system, but it also works without it. This uses CMake-type syntax, not Python, but it can generate NSIS installers, ZIP archives, binary executables on Linux, RPMs, DEBs, and Mac OS X bundles
Your requirements are probably such that hand-rolling a make script to do these things is the order of the day. Or write it in python if you don't like make. It will be more flexible and probably faster than trying to learn some proprietary scripting language from some installer creator. Anything with a fancy gui and checkboxes and so on is unlikely to be able to automatically do anything rational on linux.
perhaps paver can be made to meet your needs? you'd have to add the msi, dmg, tgz, etc parts as tasks using some external library, but i believe it can be done.