Portmod
https://gitlab.com/portmod/portmod
Previously known as OpenMMM v2.0, Portmod is a command line mod package manager that automatically downloads (when possible), configures and installs mods. The original thread for OpenMMM can be found here:
viewtopic.php?f=40&t=5672
Large amounts of credit goes to Gentoo’s Portage project (
https://wiki.gentoo.org/wiki/Project:Portage), which this is heavily based on. While I considered forking Portage, I decided instead on building from scratch a version supporting a subset of Portage’s features (though I have on occasion borrowed code), due to the size and complexity of the Portage codebase and the fact that many of its features will not be used in Portmod.
Mod descriptions for openmw, and information Portmod uses to install them, are stored in
the OpenMW Mod Repository. The repository contains one or more build files for each mod, each in a pybuild format, a variation on Portage’s ebuild format that is expressed as python code, as well as files storing repository metadata.
Current State:
The 2.0 stable release is out.
This post will no longer be updated regularly. See the
announcement mailing list, or the GitLab
releases page, for up to date information about releases.
Documentation is available on the project wiki:
https://gitlab.com/portmod/portmod/wikis/home
Also see
https://portmod.gitlab.io/openmw-mods/ to browse available packages.
Reporting Bugs
Please report any bugs you find on the GitLab issue tracker.
https://gitlab.com/portmod/portmod/issues
You can also email
[email protected] if you don't have a gitlab account.
Old News
-
Spoiler: Show
-
New Thread
While I would like to use this opportunity to announce that version 2.0 is complete, unfortunately that is not yet the case. However after some recent work, I have reached the important milestone of having completed the planned changes to the pybuild and repository formats. The remaininng features are mostly optional and non-breaking additions to the pybuild spec (texture sizes and binary patches), as well as a couple of user tools for migration. I've also taken the opportunity to merge the dev changes into master since the master branch has long since ceased to represent the current form of the project.
There are two main goals prior to the release of v2.0:
1. Fill the repository. I plan to add all mods that I can find some reference to working with OpenMW. Help would certainly be appreciated, and I will put together a guide to writing pybuilds soon. There are also currently a few missing features that will hinder adding certain mods to the repo that need to be implemented prior to 2.0.
2. Make migrating a mod setup to Portmod as hassle-free as possible. One way this will be done is to have a tool that will automatically detect manually installed mods and search for them in the repo, prompting the user to migrate them. Another is to have an archive importer that will detect, rename and move archives based on their hash so that you don't have to re-download the source archives for all the mods (particularly useful given the below note regarding Nexus Mods). Any other suggestions would be appreciated, but I think this more or less should cover it.
ModdingOpenMW.com:
I’ve been discussing with with ModdingOpenMWdotcom the possibility of working together. The combination of mod installation through portmod and exploration of available mods through moddingopenmw.com could make for a very capable and usable result.
Nexusmods.com:
It turns out that Nexus Mods only allows direct download through their API if you’re a premium user. Lacking a way to test this functionality, and preferring to avoid spending time on a feature that will only be usable for the subset of people who are premium nexusmods users, the following three things will be done for mods on NexusMods:
1. If the mod is available elsewhere with direct download, we’ll use that.
2. If the mod not available elsewhere, but its license permits redistribution, I will create a mirror somewhere and make the download available through the mirror (I will need to add support for download mirrors, but it’s not a particularly complex feature).
3. If the mod is not available elsewhere and its license does not permit redistribution, portmod will prompt the user to manually download the mod into the cache directory, and then will continue installation as usual.
Preferential Features:
I mentioned in a previous update that I’m planning functionality to handle mod ordering choices for when a user wants to prefer a certain mod over another conflicting mod (a situation where there is no “right” way to do it, essentially).
I’ve given further thought to this and came up with the idea of using a flag system, lets call them “feature” flags (admittedly the term is overloaded enough already, but I can’t think of a better name at the moment), where, for each feature flag that occurs in multiple mods you have installed, you are required to decide which mod you want to handle that feature.
For example: you might have two magic mods installed with the following flags:
mod1: magic_effects magic_spells
mod2: magic_effects magic_spells magic_potions
Suppose you prefer the changes to the effects that mod1 uses over mod2’s changes, but prefer the spells from mod2. Then you could select magic_effects: mod1, magic_spells: mod2, and magic_potions would automatically be set to mod2, since it’s the only mod that has it.
An important point here is that this is more than just choosing the ordering of the mods in the load order. Assuming that the mods support it, you could select preferences for individual features, rather than selecting preferences for all the features supported by a mod. I.e., as in the example above, you can select a feature from one mod and a feature from a different mod, even if both mods contain both features.
Unfortunately while this is relatively easy when it comes to assets (you can just remove the files that are not needed), picking and choosing features from a mod would be more difficult when those features are locked inside plugins, and short of writing mod-specific patches, the best solution would be to indicate that the mod can only provide certain features at the same time and throw an error if a certain configuration cannot be resolved.
An example of a potential use for this feature (again, way too overloaded of a term) would be to allow a texture mod to specify which things it re-textures and letting the user easily choose between multiple different texture options that are provided by different mods, for a particular thing. You could actually just install a bunch of different texture mods and go through each of the options, switching between enabled textures with just a couple of commands.
It’s worth noting that this, while not being too difficult to implement in portmod, would be quite time-consuming to implement at the repository level, since every mod that uses it would need to be set up to declare which parts of it belong to which feature. That being said, rather than micromanaging every little feature, it could just be used for large things, or as a way of resolving major conflicts, and then most mods would just ignore the subsystem entirely.
Also note that this feature system is not yet implemented and I do not plan on implementing it for v2.0. Eventually something like it will be incorporated though.
