Mixing superclass versions
I don't think this really works at the moment with Pybuild1
and Pybuild2
, but it occurred to me that for things like the MW
class in the openmw repo, individual packages which inherit from it should be able to choose which pybuild version they implement. Even when it comes to Pybuild1, the main issue was getting everything to use the new configtool VFS rather than portmod's deprecated builtin one, and fundamentally there's no problem with a package using Pybuild1 for installation, as long as it also inherits from MW
and lets that set up the json config files which configtool needs. Admittedly there are other issues with Pybuild1
, so it's not the best example, so I'm going to use the not yet implemented Pybuild3
below instead.
E.g.
class Pybuild2:
def src_install(self):
# For the purposes of this, doesn't do anything
pass
class Pybuild3(Pybuild2):
def src_install(self):
# For the purposes of this, doesn't do anything
pass
class MW(Pybuild2):
def src_install(self):
...
class Package(Pybuild3, MW):
...
For the purposes of this, Pybuild3 being a subclass of Pybuild2, but not the other way around, works well. It means that MW should target the lowest supported version, and then if you try to use something older with it you should get an mro error.
On the other hand, it means that Pybuild3's (empty) src_install
gets priority over MW
's. This isn't necessarily bad, but it's unhelpful if all you want Pybuild3 for is, for example, #363.
This could be more or less solved if Pybuild3 was to call super().src_install()
, however this isn't necessarily desirable if there are multiple install-related functions in the mro. E.g. if Pybuild3 were to include a new simplified default install (might be useful so that #395 (closed) can do something out of the box), then both that, and the install code from MW
would be run, which might not be very helpful either. But we can probably work around that as long as the interfaces are distinct (e.g. if the default install from Pybuild3 uses a field which is left empty, then it won't be an issue). It's not like it's not already possible to install things in multiple ways and ignore when they have conflicting interfaces.
Keeping things tightly-focused will help here too. MW
isn't a very good example as it both does installation, and sets up config files for configtool, and provides custom unpack functionality, and you can't separate any of them at the moment. Most of this could be solved if those things were separated and added on top of your choice of Pybuild3
or Pybuild2
, though even there we can run into MRO issues depending on the superclasses and their order.
And documentation is crucial the more options are provided. If every mod package inherits from just MW
and possibly a mixin like Git
or NexusMod
, then it's relatively straightforward, but the more options there are the more it's going to be necessary to document specifically what each class does, and what they would be compatible with. I think there used to be something mentioned on the wiki, but I think it would be much more helpful to provide generated APIdocs (and there could also be guides on the wiki when helpful).