Trying to get a Textual/Pytho/Mido app to run in Windows and Linux via PyPi/UVX

[carlca]

I have written a Python app to control the presets for the Osmose synth/keyboard. If you are on macOS, you should be able to run it using uvx osmose-presets.

The problem comes when I try to run uvx osmose-presets in Windows 11, or Linux (I'm using Mint 22.2 Cinnamon). In both cases, it fails because it cannot get the python-rtmidi library running.

PS C:\WINDOWS\system32> uvx python-rtmidi
  x Failed to build `python-rtmidi==1.5.8`
  |-> The build backend returned an error
  `-> Call to `mesonpy.build_wheel` failed (exit code: 1)

      [stdout]
      + meson setup C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src
      C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src\.mesonpy-1wc8vmq0 -Dbuildtype=release -Db_ndebug=if-release -Db_vscrt=md -Dwheel=true -Dverbose=false
      -Dbuildtype=plain --native-file=C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src\.mesonpy-1wc8vmq0\meson-python-native-file.ini
      The Meson build system
      Version: 1.9.1
      Source dir: C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src
      Build dir: C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src\.mesonpy-1wc8vmq0
      Build type: native build
      WARNING: Failed to activate VS environment: Could not parse vswhere.exe output
      Project name: python-rtmidi
      Project version: 1.5.8

      ..\meson.build:1:0: ERROR: Unknown compiler(s): [['icl'], ['cl'], ['c++'], ['g++'], ['clang++'], ['clang-cl']]
      The following exception(s) were encountered:
      Running `icl ""` gave "[WinError 2] The system cannot find the file specified"
      Running `cl /?` gave "[WinError 2] The system cannot find the file specified"
      Running `c++ --version` gave "[WinError 2] The system cannot find the file specified"
      Running `g++ --version` gave "[WinError 2] The system cannot find the file specified"
      Running `clang++ --version` gave "[WinError 2] The system cannot find the file specified"
      Running `clang-cl /?` gave "[WinError 2] The system cannot find the file specified"

      A full log can be found at C:\Users\Carl\AppData\Local\uv\cache\sdists-v9\pypi\python-rtmidi\1.5.8\Izm7r_nLUIn56WFmGbdar\src\.mesonpy-1wc8vmq0\meson-logs\meson-log.txt
      hint: This usually indicates a problem with the package or the build environment.

I've just noticed in the notes for mido that there is a possibility of using other back-end apart from python-rtmidi. My question is, therefore, should I be investigating other alternatives, and if so, how, or is there a way to get mido working with Windows and Linux?

The app was developed with Python 3.13.7 on macOS 15.6.1 with Textual 6.1.0 and midi 1.3.3. I tried installing first Python 3.13.7 on the Windows box and then Python 3.12.7 but neitehr worked.

In any case, I thought the whole point of using PyPi and uvx was that this provided a "painless', cross-platform distribution method for Python apps, without having to enter dependency hell 😉

I'd welcome any thoughts on the subject 🙏

[rdoursenaud]

Hi and thank you for your interest in mido!

The error message states that you are missing a compiler.
You need to install one to compile packages which contains some native code.
You should find the required information there: https://wiki.python.org/moin/WindowsCompilers
Feel free to ask further questions if it isn’t enough.

[rdoursenaud]

Oh, reading your original question again, I see that you have the same issue on Linux.
On a Debian based distro like Mint, installing the build-essential package should be enough:

apt install build-essential

Another way to tackle this would be by relying on system-wide libraries by installing the python3-mido and python3-rtmidi packages which will be the recommended way if you intend to provide your application in a .deb package.
Regarding packaging your application for distribution targeting Linux you may also want to take a look at Flatpak.

[carlca]

Thanks for the reply! Does that mean that I have to get the Windows end user to download and install a C++ compiler? TBH it's a bad state of affairs if I have to install a C++ compiler myself, let alone getting some other poor person to do it ;-)

How about the possibility of installing mido with PortMidi as the backend? I've tried pip install midi[PortMidi] and pip install midi[portmidi]` but either of those library names are recognised...

UPDATE: I tried that and the app ran, but the MIDI ports could not be detected...

[rdoursenaud]

Packaging a Python application for distribution is another can of worms entirely.
I suggest that you take a look at PyInstaller and Nuitka.
Both helps packaging dependencies and distributing the appropriate binaries with Nuitka also transpiling the Python code to a native executable.
Regarding the ports detection, please try in an interactive python console first and report the results from there. I’ll try and help you debug.

Edit: AFAIK all backends require a compiler at some point. It just happened to already be installed on your main workstation.

[rdoursenaud]

Also, I took a look at you application’s source code here on GitHub and it seems to have the port name kinda hardcoded in a configuration file. However MIDI port names are platform dependant and kind of hard to detect in a platform agnostic way. A better approach might be to leave the port configuration to the user while providing a list of available ports.

[carlca]

Thanks! I'm confused. I have managed to run pip install python-rtmidi on the windows machine, and it installs just fine Yet when I run uvx osmose_presets it insists on trying to build python-rtmidi even though I have carried out a non-venv installation of the same.

[rdoursenaud]

I’m not familiar with uvx (Yet) but guessing from the name it may work in the same way as pipx which creates an isolated virtual environment that does not rely on system wide libraries. This would explain why it insists on installing its own version. However, provided that the compiler is present and properly configured, it should "just work".