Using common.pybuild in place of pybuild when importing
As mentioned in #277 (closed), moving as much pybuild code repo-side as possible would help significantly when it comes to stability, however it also introduces other concerns.
One option for how this could be done is to use a common.pybuild
package (which pybuild
could alias to). My main concern is overrides.
E.g. if common.pybuild
is included in the meta
repository, what happens when the openmw
repository wants its own custom behaviour? The best option would be a separate class, which is opt-in, however if you want to ensure that all packages automatically use the new behaviour, you could instead include a new version of common.pybuild
in the openmw
repository. The issue though, is that there is no "single source of truth" for the package, as no upstream exists to dictate versions for common
packages, so any updates to meta
's common.pybuild
that increase its version would take priority over openmw
's common.pybuild
. One solution would be to use package.mask to mask the version from the meta repository, but it doesn't really address the problem that they are functionally two separate packages.
Is overriding common
packages a behaviour we want to support? I don't think it's necessary, and explicit subclasses would be better than overrides.
Perhaps, to make it more clear where common packages are being taken from, as well as structurally remove overriding from them, imports should include the name of the repository. E.g. instead of common.pybuild
, you import from meta.pybuild
, or if you want openmw's version, you import openmw.pybuild
. This also allows openmw.pybuild
's Pybuild class to inherit from meta.pybuild
's Pybuild class, where otherwise it would be a self-import. Unfortunately repository names according to the PMS aren't necessarily valid python modules, as they can contain hyphens, but it might be sufficient to say that any repository whose name contains a hyphen can't use this feature (and we can recommend that they shouldn't contain hyphens).
It also means that you can't overlap category names with any repository names (not just those in the repository's master list), which is concerning, but maybe a category prefix would help, e.g. common-meta/pybuild
instead of meta/pybuild
, or even _meta/pybuild
(interestingly the PMS allows categories to begin with underscores). The latter would actually be rather pythonic, as these are packages that users normally shouldn't interact with.
Aliases
So to maintain forwards compatibility, we could alias pybuild
to meta.pybuild
(meta repo is hardcoded anyway). There isn't an easy alias for pybuild.info
or pybuild.winreg
though the latter is only used for base/morrowind
at the moment, so it could be easily updated. It might just be easiest to provide the pybuild.info
imports as part of the base pybuild
interface, and perhaps re-exporting them via meta.pybuild
.
The other issue with aliasing pybuild
to meta.pybuild
, is what module does meta.pybuild
import the stripped-down Pybuild1
interface from? It could be _pybuild
instead.
common
could be aliased to whatever the current repository's name is.
2.0
Given that I think it should be possible to provide the aliases to ensure that existing packages are forwards-compatible, it would be possible to delay this until after 2.0 without breaking forwards-compatibility.
At the same time, given that this is a significant systemic change, it might be better to release this as part of 2.0, and have the aliases providing support for old packages, but the old import method deprecated via an inquisitor check (i.e. no runtime check to avoid annoying users, just one to ensure that new packages follow the new format).