Skip to content

Reimplemented ModInfo in a somewhat nicer manner

Benjamin Winger requested to merge bmwinger/portmod:better_modinfo into master

Diving back into perhaps the weirdest part of Portmod, the ModInfo function. I've replaced it with a new system that uses imports, so rather than modifying frames, we abuse the import system to allow importing from portmod.pybuild.modinfo to return values relevant to the pybuild.

Note that this requires deleting the cached version of the module to work (something done automatically by the pybuild loader), as otherwise the values will always be the same as the first time it was imported

Example usage:

File: example-1.0.pybuild

from portmod.pybuild.modinfo import M
print(M)

prints example-1.0.

To be honest I considered removing this functionality entirely. In Portage, it's used since package atoms generally correspond exactly to the upstream names, meaning that, for example, archive names are often simply $M.tar.gz or something similar. Here, that is unfortunately not usually the case, save for the exceptional case of omwllf, which happens to be linux software and follow the conventions. That being said, versions are generally formatted in a fairly consistent way, so it is probable that we could have downloads in the format of ExampleSuiteVersion{MV}.7z, which will probably be consistent between different releases of the mod.

Also note that making atoms match upstream names isn't a good solution either, as they are extremely inconsistent.

This is at least a reasonably good way of doing it (no more fragile than the old implementation), and allows pybuilds that use this to be considered valid by flake8 and similar tools that check defined names.

Edited by Benjamin Winger

Merge request reports