Copy uic submodule when copying PyQt5 files.

[Holt59]

As the title says, and following https://github.com/ModOrganizer2/modorganizer/issues/1065, the idea is to add the PyQt5.uic module as a dependency, since it is required to load .ui file using PyQt5.

The current module that use .ui files ship the .py generate files instead of the .py ones (e.g., preview_dds), which is fine for official plugins with a generation pipeline (these are generated by cmake). For plugins developed by external developers, it is much easier to ship the .ui file.

Since this module is a special case, I did not feel like adding it to enabled_modules and then add a if/else block in the for loop, but could do if requested.

With https://github.com/ModOrganizer2/modorganizer/issues/1067, this will ease the process of creating larger python plugins I think.

[AnyOldName3]

I'm not especially keen on this idea. Once plugins get complicated and start needing .ui files and Qt Designer and things like that, they're getting into territory where anyone creating them is going to have at least some familiarity with dev tools and willingness to install things themselves.

[Holt59]

@AnyOldName3 Well, the ones creating the plugins, yes, but not the ones using them. If I ship a plugin with a .ui file in it, then MO2 cannot use it because it does not have uic.

And I personally don't think that forcing plugin creator to generate .py files for their .ui is a good idea. In the end I would really like to have my plugin as a self-packaged Github repository and anyone wanting to use it simply has to download the archive and unpack it.

Having to generate the .py means that I have to either put the .py file in the repository, which I don't want since I already have the .ui, and to do that properly I would need to always generates the .py file when changing the .ui. Or I could create manual release, which add extra burden to the plugin creator.

In the end, I think it's a pretty small change on the MO side that may really ease the process of releasing python plugins.

[Holt59]

@AnyOldName3 After re-reading your comment maybe I misunderstood it and maybe you misunderstood the purpose of this PR.

uic is not the Qt designer, it is simply a small (~250KB) subpackage of PyQt5 that allows loading .ui file in Python without having to convert them to .py first, e.g.:

from PyQt5 import QtWidgets
from PyQt5 import uic

import os

# The directory containing the module:
MODDIR = os.path.dirname(os.path.abspath(__file__))

class SimpleInstallDialog(QtWidgets.QDialog):

    def __init__(self, name, parent):
        super().__init__(parent)
        uic.loadUi(os.path.join(MODDIR, "simpleinstalldialog.ui"), self)

[AnyOldName3]

UI files aren't really intended to be released to users. You're supposed to compile them. uic.loadUI doesn't even do all the things that the proper compiler does - inheritance and introspection don't work, for example. It seems to me that it's only intended for quick prototyping, not really for production use.

Most users installing MO2 plugins are going to see a GitHub repo as a scary hurdle and will trip up if you can't point them at a Releases page with an obvious single zip file per version, or even better, a Nexus page mirroring that download. They also aren't going to want other stuff that typically lives in a GitHub repo, like the .gitignore file, readme and licence, especially as it's likely to conflict with other plugins 'packaged' in the same way and users find conflicts scary.

We also want to encourage plugin authors to make their plugin localisable. If they're already having to run pylupdate on their source and ui, pyuic5 isn't a big extra hurdle, and vice versa. If we provide too many shortcuts, though, then as the gap between running no extra tools and just one is bigger than running one and running all of them, it'll encourage more untranslatable plugins. It's not like we can work around that by including the translation tools with MO2 as the .ts files still need to go to translators, get sent back, and be built into qm files.

[Holt59]

UI files aren't really intended to be released to users. You're supposed to compile them. uic.loadUI doesn't even do all the things that the proper compiler does - inheritance and introspection don't work, for example. It seems to me that it's only intended for quick prototyping, not really for production use.

I am not a PyQt expert, so maybe you're right, but if they work for the kind of plugin of making, I don't see anything bad with adding uic (it is not like it is breaking something).

Most users installing MO2 plugins are going to see a GitHub repo as a scary hurdle and will trip up if you can't point them at a Releases page with an obvious single zip file per version, or even better, a Nexus page mirroring that download. They also aren't going to want other stuff that typically lives in a GitHub repo, like the .gitignore file, readme and licence, especially as it's likely to conflict with other plugins 'packaged' in the same way and users find conflicts scary.

Yes but if you simply have to "Download as Archive" from Github and put it on Nexus, it's different than having to create a release manually.

Regarding other stuff included in the archive, I think this is a temporary issue that I hope to solve with https://github.com/ModOrganizer2/modorganizer/issues/1067

We also want to encourage plugin authors to make their plugin localisable. If they're already having to run pylupdate on their source and ui, pyuic5 isn't a big extra hurdle, and vice versa. If we provide too many shortcuts, though, then as the gap between running no extra tools and just one is bigger than running one and running all of them, it'll encourage more untranslatable plugins. It's not like we can work around that by including the translation tools with MO2 as the .ts files still need to go to translators, get sent back, and be built into qm files.

That's a concrete point, cannot disagree with this.

Maybe in the end it's better to have a proper "tutorial" / "startup project" for plugin creators rather than adding this.

[AnyOldName3]

Yeah, a plugin developer pack available as a separate download with each release is something I've been suggesting for a while. It would also save C++ plugin developers from having to build the whole of MO2 when all they need is UIBase headers and libs and GameFeatures headers.