Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Qt bindings mutex?

See original GitHub issue

Your question:

Hey everyone, I’d like to discuss the possibility of adding a qt_bindings_mutex package to conda-forge, similar to what we do with BLAS, MPI and others.

qt can be used from Python via two different bindings: pyqt (GPL) and pyside (LGPL). A Python interpreter process can only use one of them at a time, as far as I know. There are some wrappers (e.g. qtpy) that abstract away the differences between the two bindings, so developers can target both with a single codebase.

qtpy allows choosing the backend via QT_API. Since you can choose, qtpy does not depend on either pyqt or pyside. Still, one of them is needed, so maintainers usually add pyqt next to it. There are 47 recipes that rely on both pyqt and qtpy, which means that they could possibly work with pyside right now, but pyqt is being chosen regardless. Conversely, only 15 results show up if we query for pyside2 and qtpy.

Right now, napari is distributed with two variants to cater this use case. However, this does not prevent pyqt and pyside from being co-installed. We are considering adding run_constrained metadata to prevent this, but given the amount of packages that decided to depend on pyqt by default, this might introduce solving conflicts (when they shouldn’t be any because qtpy is supposed to make projects bindings agnostic!).

So my question is the following: would it make sense to have a qt_bindings_mutex to implement this option conda-forge wide? That way, recipes that rely on qtpy (or similar) can simply add the mutex as the dependency, and end-users can choose which one should be installed?

Issue Analytics

State:
Created a year ago
Comments:9 (7 by maintainers)

Top GitHub Comments

2reactions

hmaarrfkcommented, Jun 21, 2022

The packages themselves, in my opinion, should only depend on qtpy, no build string specified if they can.

In truth. Maybe we should create a qt-provider package. Separate from qtpy. I think creating a metapackage is a good idea. But i don’t think it should create a mutex.

Distributions, installers, environment.yaml, should specify exact package combinations.

1reaction

hmaarrfkcommented, Jun 8, 2022

I don’t think it makes sense to constrain the installation of both in the same environment.

I may want to have an GPL application co-installed with an LGPL application that speaks through interprocess communication means.

There also used to be issues with PySide2 for certain applications and vice versa.

Top Results From Across the Web

QMutex - Qt for Python

Attempts to lock the mutex. This function returns true if the lock was obtained; otherwise it returns false . If another thread has...

Reference to data inside Mutex - multithreading - Stack Overflow

Background: I am using rust-qt-binding-generator with QtQuick and I want to visualize data that is being received on the rust side ...

The Missing Article About Qt Multithreading in C++ - Toptal

In this article, Toptal Freelance Qt Developer Andrei Smirnov talks about ... all those threads would be blocked (on the mutex) before they...

Use AtomicPtr instead of Mutex · 13d8d1cf1d - rust-qt-binding ...

rust-qt-binding-generator. ... qobject: Arc<Mutex<*const DemoQObject>>, ... qobject: Arc::new(Mutex::new(file_system_tree)),.

Qt4 - Gubatron.com

Here's some code. from PyQt4.Qt import QObject, QMutex, QApplication, QThread, QMutexLocker import sys class MutexTestSubject(QObject): ''' Class that uses a ...