Qt Implementation Dependency Injection?

[harvimt]

The current system where quamash loads the first Qt Implementation it finds or one in an environment variable is hacky.

Additionally since version, author and license are loaded from init.py, a Qt Implementation (doesn't matter which one) needs to be available when setup.py is used. It would be nice if a source install could be done without PyQt/PySide being present. Even if that's unusual.

A lazy-load dependency injection type system that decides which Qt implementation to use at instantiation time could be really slick, or it could just be even more hackish.

@aknuds1 @horazont thoughts?

[horazont]

I am not very familiar with the quamash source with respect to that. Other projects (such as matplotlib) which have variable dependencies usually have a module which you can load beforehand and where you can set options:

import matplotlib
# selects backend
matplotlib.use("gtkagg")
# only here the dependencies are used
import matplotlib.pyplot as pyplot

In absence of that, quamash should fail to load, I think (In face of ambiguity, refuse the temptation to guess — Zen of Python): Most applications will only work with exactly one of the packages.

Ideally, the system would work in a way so that the type of the Qt application which is passed to the event loop determines which package to use. I wonder however how feasible that is, considering that the event loop itself already has a dependency on Qt (as it seems from looking into unix.py and windows.py; I have not looked closely though).

With a system as used by matplotlib, one could however provide a helper function such as make_loop_for_application which (a) inspects the Application object for the correct package to use, (b) calls use (or however that method would be called in quamash) and (c) imports the event loop, creates one and returns it.

just my thoughts :)

[horazont]

Another thought I had was looking for which modules are already loaded (in sys.modules) and pick whichever of the Qt packages was loaded. This is still guesswork, but better (and easier to implement) than the current approach I think.

[aknuds1]

Maybe there could be a quamash.initialize function where you specify which Qt wrapper to use (i.e., 'PyQt4', 'PyQt5' or 'PySide'). Eventually, if you pass None, Quamash could pick one automatically. For example:

quamash.initialize('PyQt5')

[harvimt]

Seems people think this is a good idea? All solutions require some
inspection/metaprogramming with regards to dynamically injecting a parent
class.
On Jan 9, 2015 4:47 AM, "Arve Knudsen" notifications@github.com wrote:

Maybe there could be a quamash.initialize function where you specify which
Qt wrapper to use (i.e., 'PyQt4', 'PyQt5' or 'PySide'). Eventually, if you
pass None, Quamash could pick one automatically. For example:

quamash.initialize('PyQt5')

—
Reply to this email directly or view it on GitHub
#16 (comment).

[horazont]

I am not sure I like that metaprogramming part. It may introduce a lot of complexity which can be easily avoided by putting QEventLoop (and related classes) into a separate module (e.g. quamash.eventloop) and requiring the user to configure quamash before importing (from) that module.

At least for a first iteration this seems more reasonable. Extending this to a more flexible approach should be possible in the future.

[harvimt]

Well I'm thinking of the things that need to happen:

A subclass of QThread is needed to make QThreadWorkers (QThreadExecutor &
QThreadWorker could totally be moved to a new module)
QObject needs to be subclassed in order for call_soon_threadsafe to work,
but this QObject subclass with custom signal need not necessarily be
QEventLoop. Finally, some sort of generic factory to create QSocketListener
instances is needed.

I think that's it.

On Fri, Jan 9, 2015 at 1:36 PM, Jonas Wielicki notifications@github.com
wrote:

I am not sure I like that metaprogramming part. It may introduce a lot of
complexity which can be easily avoided by putting QEventLoop (and related
classes) into a separate module (e.g. quamash.eventloop) and requiring
the user to configure quamash before importing (from) that module.

At least for a first iteration this seems more reasonable. Extending this
to a more flexible approach should be possible in the future.

—
Reply to this email directly or view it on GitHub
#16 (comment).

[harvimt]

I'm working on this in https://github.com/harvimt/quamash/tree/depinject

It works just not on windows (yet)