I looked this question here:
Is it possible to require PyQt from setuptools setup.py?
What's the proper way of distributing a python application that has a gui and it's based on PyQt ? (I am using PyQt5 and Python3)
I am still learning how to distribute things, so I don't know if my question makes sense.
Edit:
The answer is correct, sudo pip3 install . worked for me for my own setup.py file, but apparently pyqt5 doesn't include QtWebKitWidgets module, and it isn't available for installation in a separate package in pip3. So now I am thinking of moving away from Python completely and go with Javascript + Electron as a multiplataform easy to run language for development.
Can I require PyQt5 via setup.py?
In a word yes, as long as you restrict your support to PyQt5 and Python3.
The requirements specified in setup.py are typically provided by requesting packages from the Python Package Index (PyPi). Until recently these packages were source only, meaning that an installation depending on PyQt5 would only work on a system where it was possible to build it from source. Building on Windows in particular requires quite a lot of set up, and this would therefore put your application out of reach for anyone unable or unwilling to do this.
Note: As far as I am aware, it was never actually possible to build from source via PyPi. The standard approach was to download the source/binaries from Riverbank Software and build/install from there.
This problem was solved by the introduction of Python Wheels which provide a means to install C extension packages without the need for compilation on the target system. This is achieved by platform-specific .whl files. Wheels for PyQt5 on Python3 are available on PyPi for multiple platforms, including MacOS X, Linux (any), Win32 and Win64 which should cover most uses.
For example, this is the output when pip-installing PyQt5 on Python3 on a Mac:
mfitzp#MacBook-Air ~ $ pip3 install pyqt5
Collecting pyqt5
Downloading PyQt5-5.6-cp35-cp35m-macosx_10_6_intel.whl (73.2MB)
100% |████████████████████████████████| 73.2MB 2.5kB/s
Collecting sip (from pyqt5)
Downloading sip-4.18-cp35-cp35m-macosx_10_6_intel.whl (46kB)
100% |████████████████████████████████| 49kB 1.8MB/s
Installing collected packages: sip, pyqt5
Successfully installed pyqt5-5.6 sip-4.18
To set PyQt5 as a dependency of your own package simply specify it as normal in your setup.py e.g. install_requires=['PyQt5']
What's the proper way of distributing a Python GUI application?
Here you have a few options. The above means that anyone with Python3 installed can now install your application using pip. However, this assumes that the end-user has Python and knows what pip is. If you are looking to distribute your application with a Windows installer, MacOSX 'app' bundle, or Linux package, you will need to use one of the tools dedicated to that purpose.
Windows
cx_Freeze is a cross-platform packager that can package Python applications for Windows, Mac and Linux. It works by analysing your project and freezing the required packages and subpackages. Success depends largely on which packages you depend on and their complexity/correctness.
PyInstaller is another cross-platform packager that can package Python applications for Windows, Mac and Linux. This works in a similar way to cx_Freeze and will likely perform both better/worse depending on the packages.
PyNSISt builds NSIS installer packages for Windows. This has the advantage of being very straightforward: it simply packages all the files together as-is, without 'freezing'. The downside is that packages can end up very large and slower to install (but see the file-filter options). It now supports bundling of .whl files which will solve this in many cases. By far the easiest if you're targeting Windows-only.
MacOSX
cx_Freeze see above.
PyInstaller see above.
Py2app creates .app bundles from the definition in your setup.py. Big advantage is the custom handlers that allow you to adjust packaging of troublesome packages. If you're only targetting MacOSX this is probably your best option.
Linux
cx_Freeze see above.
PyInstaller see above.
stdeb build Debian-style packages from your setup.py definition.
Note: It is possible to write a very complex setup.py that allows you to build using one or more tools on different platforms, but I have usually ended up storing separate configs (e.g. setup-py2app.py) for clarity.
Related
I'm trying to build a speech recognition application that works in a browser. Currently using pyodide with a web worker. I have my own package, built alongside pyaudio, that I use for the web worker.
Is there a way that I can include a brew instillation, specifically portaudio, inside of my python package so that when I build the package, portaudio is included in the wheel file? I need portaudio included for this to work in the browser.
Thank you!
I'm understanding two different questions here, so I'll try to answer them both.
Can I have a python build fetch a Homebrew project during buildtime
To my knowledge, the answer is no. The Python distribution system is separate from Homebrew, and they can't interact in this fashion.
Even if they could, this wouldn't necessarily be desirable:
What happens if the user isn't on macOS (or Linux)? Then the build would fail.
The prefix that Homebrew will install the package in isn't very deterministic. The user might be using a custom prefix, or they might be on Apple Silicon (which has a different default prefix to Intel).
Your python package might run into some difficulty locating the package.
What about if they don't have Homebrew installed? They might have another package manager like MacPorts or Fink, or maybe none at all.
Can I bundle portaudio into the build distribution?
Maybe? Even if you could, I almost certainly wouldn't recommend it.
Bundling dependencies increases the size of the distribution unnecessarily.
It would take a reasonable amount of effort to setup, assuming you can do it.
All these reasons are why for the majority of projects that have a similar setup, you will find that they recommend installing certain packages with their system package manager first, before building the Python source code.
This allows them to choose whatever package manager they have installed, and it should also be a quick and painless process.
Therefore, just change your installation instructions to the following:
# On macOS
brew install portaudio
pip install ...
I have implemented pyodide in browser for small web apps. Some python package have no pure python wheel so I have built locally then uploaded to CDN. This python wheel can be installed using micropip in pyodide.
So my questions, is there way to build the wheel in browser for pyodide. What will be difficulty for implementing this?
I am curious to know.
Thanks
To the extent that a wheel of a pure Python packages consists of some Python files with metadata, packaged as a ZIP file, you can certainly create such an archive in Pyodide.
In practice though, wheels are most commonly created with setuptools or the wheel package which has following challenges for pyodide:
setuptools, at least, uses the subprocess module which is not supported in WebAssembly VM, meaning that it would need to be patched to avoid making subprocess calls
install requirements in setup.py (and build requirements in pyproject.toml) imply that one is able to download and install dependencies with pip which poses its own chalenges, namely,
the use of subprocess in pip / setuptools
fetching of packages with standard python modules also doesn't work (no sockets in WASM) unless ones rewrites some of them with Web API pyodide#140
For those reason, micropip was written as very rudimentary alternative to pip in the context of pyodide.
It's also a good idea to create wheels for pure python packages even for Python on classical architectures, as they don't require arbitrary code execution to install. Which means that wheels are safer, more reliable and faster to install.
Does anyone know where I can find a pip-install for PySide2?
It's 2017 and I can't seem to find a pip install or site-package containing the binaries for PySide2. I prefer not to deal with downloading the source code and compiling it myself, as that usually ends up being a huge headache as it's never a smooth process. Also considering it's highly likely someone else has already done it. If I were to be honest here, if I attempted to compile it myself and errors popped up, I wouldn't really know where to begin solving them, nor do I want to spend time doing that.
I just find it hard to believe I can't find it anywhere online or even in PIP when a lot of applications in the VFX industry are switching to PySide2.
I hope someone can help me out.
Thanks
Same Problem...
So i tried to build it. But there are Problems building the WebKit.
Hence my windows binaries are actually without a webkit binding.
You can obtain it through PyPI:
pip install PySide2
or if it fails (most likely because your pip executable is bound to python 2) try:
pip3 install PySide2
or even better:
python -m pip install Pyside2
This assumes that python is bound to Python 3, that way you're really sure about the Python version used, see Why you should use python -m pip.
There are wheels available by Fredrik Averpil here built with Qt 5.6.
Claudius Hansch's answer provides a wheel using Qt 5.9.
In any case, don't forget to either
set the QT_QPA_PLATFORM_PLUGIN_PATH environment variable as described here
or
create a qt.conf file in the folder of your python.exe with the content
[Paths]
Prefix = /dir_to_site-packages/PySide2
Binaries = /dir_to_site-packages/PySide2
PySide2 is now available on pypi so a simple
pip install PySide2
should work on Windows, OSX, and linux!
I use Python 3.7 on windows 10 pro, 64bit.
Installing via pip failed for me.
I ended up downloading the wheel from qt directly
QT official download page
and install the downloaded wheel which worked fine.
This question already has answers here:
What is a Python egg?
(4 answers)
Closed 6 years ago.
When I need a Python library, I use pip to fetch it from PyPi and if I create a project and want to share it, I just need to have in place the setup.py file and that would make it easily installable. Therefore, I was wondering what is the use case for egg or wheel packages.
The Python Packaging User Guide has to say the following on this topic:
Wheel and Egg are both packaging formats that aim to support the use case of needing an install artifact that doesn’t require building or compilation, which can be costly in testing and production workflows.
These formats can be used to distribute packages that contain binary extension modules. These would otherwise require compilation during installation.
If no compilation is involved a source distribution is in principle sufficient, but the user guide still recommends to create a wheel for performance reasons:
Minimally, you should create a Source Distribution:
python setup.py sdist
A “source distribution” is unbuilt (i.e, it’s not a Built Distribution), and requires a build step when installed by pip. Even if the distribution is pure python (i.e. contains no extensions), it still involves a build step to build out the installation metadata from setup.py.
[...]
You should also create a wheel for your project. A wheel is a built package that can be installed without needing to go through the “build” process. Installing wheels is substantially faster for the end user than installing from a source distribution.
In short, packages are a convenience thing - mostly for the user.
Wheel packages unify the process of distributing and installing projects that contain pure python, platform dependent code, or compiled extensions. The user does not need to worry if the package is written in Python or in C - it just works.
Egg packages are an older standard, you should ignore them nowadays. Use pip install . instead of ./setup.py install to prevent creating them. (addendum: They are also .zips in disguise, from which Python reads package data — not exactly the most performant solution)
Wheel packages, on the other hand, are the new standard. They allow for creation of portable binary packages for Windows, macOS, and Linux (yes, Linux!). Nowadays, you can just do pip install PyQt5 (as an example) and it will just work, no C++ compiler and Qt libraries required on the system. Everything is pre-compiled and included in the wheel. Non-binary packages also benefit, because it’s safer not to run setup.py (all the metadata is in the wheel). (addendum: those are also .zips, but they are unpacked when installed)
I am currently attempting to install a third-party package (gnuradio, to be specific) into the Canopy version of Python on an Ubuntu computer. I currently have the entire package stored in my filesystem as a folder with subfolders and python files; however, I have been able to find no information as to how to make the transition into a functionally installed and recognized package. How can I do so?
You shouldn't use third party pythons on Ubuntu, unless you very exactly know what you're doing (you don't). Ubuntu keeps your python up-to-date and uses the package manager to install pack
So, setting up a recent version of python is just
sudo apt-get install python
So if you still want to integrate GNU Radio into your canopy installation, you will need to get the development headers of exactly their version of python, and specify that you want to only use them etc, and build GNU Radio from source. I do not recommend doing that.
In my opinion, you should probably rather install GNU Radio either from source against the python and libraries on your main OS rather than canopy's happy little installation folder, or use the gnuradio package that Ubuntu has.
I recommend using pybombs to install GNU Radio from source. You'll get the latest and greatest, in a safe install prefix, and easy access to bleeding edge SDR device drivers.
(1) Python packaging is inconsistent, but in general, it suffices to type python setup.py install from the package's top directory (see https://docs.python.org/2/install/#the-new-standard-distutils)
(2) How to be sure that you are installing into Canopy Python rather than your system Python? See https://support.enthought.com/entries/23389761-Installing-packages-into-Canopy-Python-from-the-command-line (tl;dr open a Canopy Terminal window from the Canopy Tools menu.)
EDIT: Marcus Müller has clarified below that gnuradio is not a python package, so this general advice is true but irrelevant. See his answer below.