I'm trying Pypy because it shows impressive benchmarks over CPython. Also, I'm mostly using the Twisted library in my code. I can now run a benchmark script which uses the Twisted reactor so I guess my setup is good. However, I do not know how to run the Twisted daemonizer (twistd) using Pypy.
You can either do it explicitly at run-time:
~$ /usr/bin/pypy /usr/bin/twistd ...
This works because it specifically starts PyPy and tells it to start interpreting the twistd script.
Or you can do it persistently at install-time:
~/Twisted-11.0.0$ /usr/bin/pypy setup.py install
This works because distutils (what setup.py uses) rewrites the #! line of each script it installs to point to the interpreter used to do the installation. So #!/usr/bin/env python in the installation source becomes #!/usr/bin/pypy in the installed copy.
Related
I am running WSL2 under Windows 10.
If I type "gedit &" into the WSL console, the Gedit application window pops up. Thus I assume that WSLg properly works.
Next, I am trying to run the following PyQt5 project:
https://github.com/rafaelpadilla/review_object_detection_metrics
However, no application window pops up this time, although no error message appears either.
First of all, I do wonder whether this could work at all with WSL!?
Appendix for additional context:
I am not using conda because of licensing issues, but a combination of pyenv + poetry instead. First I had problems with a missing library (libxcb.so), which I could solve by running "sudo apt python-pyqt5". Now everything seems to work, except from no application window being shown.
UPDATE:
I tried with "/src/pyqt-official/qtdemo/qtdemo.py" from the official PyQt Examples github repository and I observed exactly the same issue.
There is no error message. Last prompt informs me that the "xcb plugin was loaded“, then nothing happens. In particular, no window is showing up.
Some related observations:
(1) I haven't yet updated my grafics card driver to support vGPUs. However, Gedit works and opens in a separate window.
(2) Unless I do "sudo apt install python3-pyqt", I receive an error message saying that it cannot find "libxcb.so". However, I am running the code in a virtual pyenv/poetry environment, which is separate from the system python installation. I don't understand why "sudo apt install python3-pyqt" makes a difference here. Shouldn't installing "PyQt5" with poetry obtain a wheel that comes with all libraries already compiled? I don't understand how all of this is playing together.
Open Questions:
Do you think the driver issue could be an explanation? I actually cannot imagine that. I thought it is only about better performance for OpenGL applications.
Can you explain observation (2)?
What else can I do?
First of all, I do wonder whether this could work at all with WSL!?
I can't tell you if that particular application will run under WSL, but my expectation is that it will. As far as I can tell in its dependencies there doesn't seem to be any reliance on GPU compute. That, to me, would be the trickiest part to configure under WSL (but is still typically possible). However, there may be other dependencies (not covered below) that you need to get running before the application can work.
What I can confirm is that PyQt works under WSL just fine. However, keep in mind that a default Ubuntu installation under WSL is based on a non-GUI Ubuntu Server distribution, rather than standard Ubuntu (with a desktop and GUI).
This means that Ubuntu Server is often missing system level libraries needed for GUI support, which appears to be the case here.
I don't understand why "sudo apt install python3-pyqt" makes a difference here. Shouldn't installing "PyQt5" with poetry obtain a wheel that comes with all libraries already compiled?
Poetry and/or Pip manage the Python library dependencies, but those Python libraries still require the native system library dependencies. That's where sudo apt install python3-pyqt5 comes in. Under a desktop Ubuntu system, most of these libraries would already be in place. However, with Ubuntu Server/WSL, they aren't.
For reference, here's my configuration. On a freshly initialized Ubuntu 22.04 WSL2 distribution:
sudo apt update && sudo apt upgrade -y
sudo apt install python3-venv python3-pyqt5
mkdir -p src/pyqt_test
cd src/pyqt_test
python3 -m venv .venv
source .venv/bin/activate
pip install pyqt5
I was then able to create and run the following, taken from Learn Python PyQt:
import sys
from PyQt5 import QtWidgets
app = QtWidgets.QApplication(sys.argv)
windows = QtWidgets.QWidget()
windows.resize(500,500)
windows.move(100,100)
windows.show()
sys.exit(app.exec_())
The window displayed correctly.
I'm running a Windows computer with just a CPU (no GPU). When I run pip install tensorflow -vvv in order to see what pip is doing, it lists a lot of links, but for all of them, it says "Skipping link ... it is not compatible with this Python."
Does tensorflow support Python 3.6.4 on Windows? If so, what binary URL should I use to install it?
(I previously installed with this version due to reading this, but ran into this error without the DLL load failed message, so I'm wondering if there's a better version I should use.)
Also, I'm aware that Tensorflow says they support Python 3.x, but right now it hasn't been working for me.
You have probably installed Python 32bits, you need the 64bits version
I'm trying to understand why the easy_install of pyicu works and pip install doesn't (see below). also trying to understand "What is the difference between a PyPi project with a universal wheel and one without?" Will installs be "easier?". If so, will this merge request solve the problem of polyglot not installing on an Anaconda machine?
Need help/advice/solutions on how to best resolve python project install issue that is tied to underlying dependencies. I have two local fixes in GitHub Gists but would like to know the best way to have this fix "out there" so people like me can find it. What is the normal Python Community approach? The problem centers around three projects:
polyglot - a python multilingual NLP toolkit
pyicu - Python extension wrapping IBM's International Components for Unicode C++ library (ICU).
pycld2 - CLD (Compact Language Detection) library as maintained by Dick Sites
The goal:
Install polyglot on a MacOSX computer running Python Anaconda Distribution
Make the fix I found available to everyone; lots of issues published about the problem.
Here's the error trace:
The Problem (Lots of them):
Core polyglot dependency, pyicu, does not properly install when you use pip install. Discovered you must use easy_install for it build properly and work on MacOSX. If you don't use the easy_install, you get:
polyglot requires icu 54.1.1 to run in Anaconda, but...
Homebrew, the MacOSX tool to install icu, only installs version 58.1. That version is too new. Old stackoverflows advise brew install icu4c to fix problem, but Homebrew evolution makes that advice obsolete now.
pyicu does not have a universal wheel; but I created a merge request to add one to pyicu. Only way to fix this is with this channel's icu, https://anaconda.org/ccordoba12/icu. conda install icu will not work, but that's the normal conda way of doing things.
*pycld2 - CLD (Compact Language Detection) becomes a problem because after I build the wheel file locally, have to download the project and run setup.py install locally. There has to be a better way to do this right?
What I've Done to Solve the problem (should I do more, what should I do next?)
Created two Gists that can successfully install polyglot on a Mac running Anaconda for Python 2.7 or Python 3.5
Python 2.7 fix
Python 3.5 fix
created the merge request for pyicu
Both Gist fixes work. But, is this error in install tied to the wheel? If I installed pyicu with easy_install, the install works. But, with pip, it doesn't?
What are the steps to take in the Python community to fix it so people can find the solution or just pip install with no problems?
I did a test, and if the wheel file is built, the pip works with no issues.
I tried installing Gnuradio 3.7.9.2 using build-gnuradio script and apart from a few hiccups due to some packages (which I installed and re-ran the script again) , the script completed its run successfully (I enabled the verbose option of the script to check the output). I even added the PYTHONPATH to the .bashrc script after completing the installation. When I tried launching gnuradio-companion though, it doesnt recognise the command.
:~$ gnuradio-companion
The program 'gnuradio-companion' is currently not installed. You can install it by typing:
sudo apt-get install gnuradio
So, I was wondering whether I need to install grc separately after the build-gnuradio script installation ?. I apologise if this is too simple, I have tried the installation many times and searched the web for problems like this. To the best of my efforts, I was not able to find any. It would be great, if anyone can point to any existing question similar to this, or guide me in fixing this issue. Thank you.
It is advised to use PyBOMBS to install GNU Radio. Installing Out-of-Tree modules (OOTs) will be much easier afterwards. As for your problem: Did you check if your $PATH variable (echo $PATH) contains /usr/local/bin/? This should be the default installation path for a non-system install of GNU Radio.
Alternatively you can try to run /usr/local/bin/gnuradio-companion.
I have installed virtualenvwrapper in a 3.5.0b1 virtualenv, called setupenv, to be able to generate new python 3.5 test environments easily.
Looking over the list of installed packages, I did see argparse version 1.3.0 installed. This (latest) version of argparse has not been tested with 3.5.
Is this dangerous?
As far as I know 3.2+ comes with its own argparse. Could this install break other packages relying on argparse? Why is this installed at all?
This is probably not dangerous. If you run:
python3.5 -c "import argparse; print(argparse.__file__)"
, you can see that the arparse.py installed with the interpreter takes precedence over the superfluously installed argparse package.
A bit of digging (or using the pipdeptree package) will show you that stevedore is dependent on argparse. This is just sloppy programming (or disregard of possible bandwidth issues).
In a package's setup.py you can easily test if you are running python < 2.7 or 3.0 <= python < 3.2 and only install argparse for those cases.
I would just de-install argparse from your setupenv virtualenv (pip uninstall argparse -y), virtualenvwrapper is not affected by the removal in my experience.
This is actually a bug in stevedore, it uses the pbr package and that supports specification of the python version using environment markers
but stevedore is not using that. The irony is that the example for this in pbr is with argparse, by specifying in the requirements.txt:
argparse; python=='2.6'
A bug report against stevedore was filed, but although the fix was trivial, it was not implemented for several releases. Finally the issue was
set to won't fix, probably because dropped support for 2.6 removed the
need for argparse altogether.