I'm considering getting my hands on a large library of .ui files with which to test this out on. Sort of as an optional "catch-all" in addition to the more refined and specific tests like the one included here.

For that, how about finding say, 10.000 of them from GitHub via a specific search query, storing them all in a Gist for reproducibility, and download them during testing to be run through the same conversion mechanism?

More discussion on Python Inside Maya.

how about finding say, 10.000 of them from GitHub

This didn't work, here's why.

1. My first approach was to utilise the GitHub Search API, but as it turns out, they've put an artificial limit on searching via the API. The limitation is that each query must include either a user, repository or organisation. This thwarts the attempt, as the idea was based on finding all .ui files, regardless of project or any other metric.
2. Since this limitation was not put on the web frontend of their search engine, I figured I'd just scrape it. But, after some investigation, it turns out they have employed clever mechanisms (or at least, cleverer than me) to prevent just such attempts.
3. Finally, I resorted to grabbing just a few and start with that. Turns out, searching for this particular format is (1) not precise enough to guarantee that all files found is actually Qt Designer files and (2) how can I know that these files work from the outset?

So I'll now resort to collecting any .ui files you have lying around. Let me know!

I'm considering releasing this as-is as an alpha.

Currently, when you run it, this happens.

$ python -m Qt --help
usage: Qt.py [-h] [--convert CONVERT] [--compile COMPILE] [--stdout] [--stdin]

optional arguments:
  -h, --help         show this help message and exit
  --convert CONVERT  Path to compiled Python module, e.g. my_ui.py
  --compile COMPILE  Accept raw .ui file and compile with native PySide2
                     compiler.
  --stdout           Write to stdout instead of file
  --stdin            Read from stdin instead of file
$ python -m Qt --convert my_ui.py
#
# WARNING: --convert is an ALPHA feature.
#
# See https://github.com/mottosso/Qt.py/pull/132
# for details.
#
Creating "my_ui_backup.py"..
Successfully converted "my_ui.py"
$ 

Which should be enough to keep people from relying on it, but inviting enough for them to try and find problems for us to expel.

@fredrikaverpil What do you think of all this?

Ok, I'm back from my honeymoon 😄

I use .ui files (from Qt Designer) and load those as they are without converting them (this means using Qt.py's load_ui). So I'm not entirely sure how this should work. I just attempted to do a conversion from .ui to .py:

$ python -m Qt --convert main_window.ui

#
# WARNING: --convert is an ALPHA feature.
#
# See https://github.com/mottosso/Qt.py/pull/132
# for details.
#
Creating "main_window_backup.ui"..
Successfully converted "main_window.ui"


$ ls -alh main_win*
-rwxr-xr-x  1 fredrik  staff   2.4K Sep 14 07:16 main_window.ui
-rwxr-xr-x  1 fredrik  staff   2.4K Sep 14 07:16 main_window_backup.ui

I'm not sure what I'm doing wrong. Perhaps you never go from .ui to .py?

--convert takes an already compiled Python module from pyside2-uic and makes a Qt.py-compatible version.

I think it looks fine to merge this, especially since you're mentioning it's an alpha. I can't say I know much about this feature.

Do you want to include something on this in the README?

Welcome back, by the way! Sorry, was deep in thought as I wrote the reply.

The feature is in relation to #99 and #129, and #131 is the source issue.

In short, some users, like yourself, prefer load_ui whereas others prefer compiling to Python. But compiling to Python means embedding traces from the original binding into the resulting code, like from PySide2 import QtGui.

This is an attempt at solving this problem by way of the command-line, the same environment in which files are compiled in the first place.

I was hoping to also have the --compile flag in there to take a .ui file and run pyside2-uic for you, but I haven't been able to get my hands on a working version of this yet (hint hint).

Other than that, it needs testing. If you have any .ui files lying around, could you put them up in a gist or the like? Then we can fetch those during Travis testing.

So when you use the --compile option you're supposed to be able to get a binding-agnostic/Qt.py compatible .py based on the given .ui file. Ok, that makes sense.

About pyside2-uic, I think it's part of pyside-tools, which doesn't seem to be compiled when building pyside-setup and thus not included in the PySide2 wheel.

But what's the use case for the --convert option then?

So when you use the --compile option you're supposed

--compile would be shorthand for:

# This
$ pyside2-uic my_ui.ui -o my_ui.py

# Is this
$ python -m Qt --compile my_ui.ui

It's to highlight the fact that the only compiler you can use is the one from PySide2.

But what's the use case for the --convert option then?

When used in conjunction with --convert, you get a one-stop-shop.

$ python -m Qt --compile --convert my_ui.ui
$ cat my_ui.py

Okay, now I get it. Thanks for that explanation :)

Do you have access to Maya 2017?
I can see pyside2uic is included with Maya's Python site-packages as its own package. You might be able to copy this module into your own site-packages (just for testing purposes).

Do you have access to Maya 2017?

I do, but I'm looking to include tests for this and need it accessible somehow via the Docker image.

For completion... I managed to find the built package and manually copy it into my site-packages. Then I also copied the built binary. Details here.

Ok, let's get this on the road for testing as-is, then continue working on it through more issues and PRs.

Any objections?

No objections!