[GH-ISSUE #244] Allow users to easily expand images

bsakaguchi commented

2026-10-15 12:48:42 +00:00

Owner

Originally created by @shawly on GitHub (Jun 22, 2025).
Original GitHub issue: https://github.com/games-on-whales/gow/issues/244

I am just in the middle of tinkering around with installing my GoG library inside my Steam container and had to install some dependencies which were missing in my compatdata. So I had to install protontricks inside the container to make that process easier for me.
Also to get proper cover art for non-Steam games in my library I use Steam ROM Manager which automates this for me.

So I wanted to add a new PR for adding protontricks to the steam base image if that is desirable?

I also wondered if it would be a good idea to integrate Steam ROM Manager into the image as well, as it's very useful for non-Steam shortcuts?

I'm missing some development guidelines on how much "bloat" should be shipped with am image. Because I don't want to spam PRs with stuff I think is useful, but other people think is not. Like in my opinion protontricks is a given on a Linux system, but SRM is kinda optional maybe. I also thought about adding an ENV var that allows installing additional packages, but such a think does increase startup time depending on how much stuff is added.

I also think it might be a good idea to add an archlinux based steam image or rather a base image, as gaming on linux often benefits from bleeding edge packages. But I could understand if you didn't want to give support for two kinds of base images. Maybe even migrate all images to Arch?

What is your opinion on that topic @ABeltramo ?

Originally created by @shawly on GitHub (Jun 22, 2025). Original GitHub issue: https://github.com/games-on-whales/gow/issues/244 I am just in the middle of tinkering around with installing my GoG library inside my Steam container and had to install some dependencies which were missing in my compatdata. So I had to install protontricks inside the container to make that process easier for me. Also to get proper cover art for non-Steam games in my library I use [Steam ROM Manager](https://github.com/SteamGridDB/steam-rom-manager) which automates this for me. So I wanted to add a new PR for adding protontricks to the steam base image if that is desirable? I also wondered if it would be a good idea to integrate Steam ROM Manager into the image as well, as it's very useful for non-Steam shortcuts? I'm missing some development guidelines on how much "bloat" should be shipped with am image. Because I don't want to spam PRs with stuff _I think_ is useful, but other people think is not. Like in my opinion protontricks is a given on a Linux system, but SRM is kinda optional maybe. I also thought about adding an ENV var that allows installing additional packages, but such a think does increase startup time depending on how much stuff is added. I also think it might be a good idea to add an archlinux based steam image or rather a base image, as gaming on linux often benefits from bleeding edge packages. But I could understand if you didn't want to give support for two kinds of base images. Maybe even migrate all images to Arch? What is your opinion on that topic @ABeltramo ?

bsakaguchi added the

enhancement

label

2026-10-15 12:48:42 +00:00

bsakaguchi commented

2026-10-15 12:48:42 +00:00

Author

Owner

@ABeltramo commented on GitHub (Jun 22, 2025):

I'm missing some development guidelines on how much "bloat" should be shipped with am image.

You are missing them because we've never defined them properly. 😅

It's a tough balance: on one side, the more packages we add the bigger the image size becomes and, more importantly, a bigger burden on us when there's inevitably something broken (see the latest fixes after upgrading the base image to Ubuntu 25.04). On the other side, obviously if we strip them too much then non-technical users will not be able to use Wolf as they would like to.

Ideally, I would like GOW to be a set of simple core base images that the community can easily expand on. The main idea behind the wildlife website was to have a central place where we could list all "wolf compatible images" and to also list "community provided images". A possible first entry would be for example Dolf, tracked in this issue. I'm just swamped between Wolf, GOW and community support on Discord so if anyone would like to help expand on this front it would be greatly appreciated!

Ultimately, this collection of images will be presented to users via WolfManager web-ui so that users can easily plug, play (and possibly keep updated) all the images that they really care about.

This is kind of the high level plan, what do you think?

I also thought about adding an ENV var that allows installing additional packages

I'm not against that, it's an easy way for anyone to easily test potential missing packages and get around dummy issues like the ones that we've experienced recently when upgrading Ubuntu. A custom script that does that on startup, possibly on the base image under /etc/cont-init.d/ would be perfect, and I'd merge it in an instant.

Another great solution that I love is allowing flatpak to install in the home folder, like we do in XFCE. It just integrates so well with everything that we do!

@ABeltramo commented on GitHub (Jun 22, 2025): > I'm missing some development guidelines on how much "bloat" should be shipped with am image. You are missing them because we've never defined them properly. 😅 It's a tough balance: on one side, the more packages we add the bigger the image size becomes and, more importantly, a bigger burden on us when there's inevitably something broken (see the latest fixes after upgrading the base image to Ubuntu 25.04). On the other side, obviously if we strip them too much then non-technical users will not be able to use Wolf as they would like to. Ideally, I would like GOW to be a set of simple core base images that the community can easily expand on. The main idea behind the [wildlife website](https://games-on-whales.github.io/wildlife/) was to have a central place where we could list all "wolf compatible images" and to also list "community provided images". A possible first entry would be for example Dolf, tracked in [this issue](https://github.com/games-on-whales/gow/issues/209). I'm just swamped between Wolf, GOW and community support on Discord so **if anyone would like to help expand on this front it would be greatly appreciated!** Ultimately, this collection of images will be presented to users via [WolfManager](https://github.com/games-on-whales/wolfmanager) web-ui so that users can easily plug, play (and possibly keep updated) all the images that they really care about. This is kind of the high level plan, what do you think? ------ > I also thought about adding an ENV var that allows installing additional packages I'm not against that, it's an easy way for anyone to easily test potential missing packages and get around dummy issues like the ones that we've experienced recently when upgrading Ubuntu. A custom script that does that on startup, possibly on the `base` image under `/etc/cont-init.d/` would be perfect, and I'd merge it in an instant. Another great solution that I love is allowing flatpak to install in the home folder, like we do in XFCE. It just integrates so well with everything that we do!

bsakaguchi commented

2026-10-15 12:48:42 +00:00

Author

Owner

@shawly commented on GitHub (Jun 23, 2025):

Thanks for your elaborate answer! I definitely agree with all your points!
Integrating flatpak would definitely solve the need for integrating protontricks and SRM inside the Steam image! After I added protontricks and SRM to my fork, the steam image in my docker lib grew from 1.9G to 3.6G so I basically answered the question myself, because that's definitely too big.

A custom script that does that on startup, possibly on the base image under /etc/cont-init.d/ would be perfect, and I'd merge it in an instant.

The linuxserver community added a pretty neat way of expanding an image post build with their docker mods (https://github.com/linuxserver/docker-mods). I think something like this would improve extensibility immensely as it would allow extending images with complete feature-packs instead of just packages, without the need of having to build a fork that people would have to use instead.

I'm also a big fan of the s6-overlay which linuxserver images also use and I also integrate into all docker images I personally maintain. That would help with more complex additions if wolf/gow ever adapted a similar feature like the docker-mods. Also having a lightweight init system is definitely preferable for such complex images in my opinion.

I'd be glad in attempting to implement this and open a PR!
Though migrating to s6-overlay would definitely be a pretty big PR and introduce breaking changes to all community images that are based on the base images. But that is technically expected when using "edge" images though.
Also a big plus for s6 is that it would future proof the docker images overall as using the s6-overlay is pretty streamlined. I'm mentioning this because I've noticed that all app images are kinda all over the place when it comes to where scripts are placed and in which order they are executed, having a pre-defined structure of where scripts have to go is in my opinion a good thing and will likely introduce less breaking changes for community images in the future.
And s6 also reaps zombie processes, which are likely to occur in such environments where games might crash.

Integrating flatpak would also come with these changes of course!

@shawly commented on GitHub (Jun 23, 2025): Thanks for your elaborate answer! I definitely agree with all your points! Integrating flatpak would definitely solve the need for integrating protontricks and SRM inside the Steam image! After I added protontricks and SRM to my fork, the steam image in my docker lib grew from 1.9G to 3.6G so I basically answered the question myself, because that's definitely too big. > A custom script that does that on startup, possibly on the base image under /etc/cont-init.d/ would be perfect, and I'd merge it in an instant. The linuxserver community added a pretty neat way of expanding an image *post build* with their docker mods (https://github.com/linuxserver/docker-mods). I think something like this would improve extensibility immensely as it would allow extending images with complete feature-packs instead of just packages, without the need of having to build a fork that people would have to use instead. I'm also a big fan of the [s6-overlay](https://github.com/just-containers/s6-overlay) which linuxserver images also use and I also integrate into all docker images I personally maintain. That would help with more complex additions if wolf/gow ever adapted a similar feature like the docker-mods. Also having a lightweight init system is definitely preferable for such complex images in my opinion. I'd be glad in attempting to implement this and open a PR! Though migrating to s6-overlay would definitely be a pretty big PR and introduce breaking changes to all community images that are based on the base images. But that is technically expected when using "edge" images though. **Also** a big plus for s6 is that it would future proof the docker images overall as using the s6-overlay is pretty streamlined. I'm mentioning this because I've noticed that all app images are kinda all over the place when it comes to where scripts are placed and in which order they are executed, having a pre-defined structure of where scripts have to go is in my opinion a good thing and will likely introduce less breaking changes for community images in the future. And s6 also reaps zombie processes, which are likely to occur in such environments where games might crash. Integrating flatpak would also come with these changes of course!

bsakaguchi commented

2026-10-15 12:48:43 +00:00

Author

Owner

@ABeltramo commented on GitHub (Jun 23, 2025):

Thanks for the pointers!
I've briefly looked at linuxserver/docker-mods in the past but never went too deep into it, and I was intrigued by proot-apps which sounds like a very good fit for us. I didn't know about s6-overlay and I agree, it sounds like we definitely can benefit from a proper init system and some more structure in our images!

Though migrating to s6-overlay would definitely be a pretty big PR and introduce breaking changes to all community images that are based on the base images. But that is technically expected when using "edge" images though.

We don't have anything stable (hence the :edge tag), and I don't mind possibly breaking something if we end up with a more robust and easily extensible solution. Also, nothing is forced to users; everyone is free to use any image!

P.S. despite the edits, I've got the original message via email; please don't worry about committing to anything. We are all here in our free time to experiment and possibly have fun in the process, no strings attached 😜

@ABeltramo commented on GitHub (Jun 23, 2025): Thanks for the pointers! I've briefly looked at `linuxserver/docker-mods` in the past but never went too deep into it, and I was intrigued by [proot-apps](https://github.com/linuxserver/proot-apps) which sounds like a very good fit for us. I didn't know about `s6-overlay` and I agree, it sounds like we definitely can benefit from a proper init system and some more structure in our images! > Though migrating to s6-overlay would definitely be a pretty big PR and introduce breaking changes to all community images that are based on the base images. But that is technically expected when using "edge" images though. We don't have anything stable (hence the `:edge` tag), and I don't mind possibly breaking something if we end up with a more robust and easily extensible solution. Also, nothing is forced to users; everyone is free to use any image! P.S. despite the edits, I've got the original message via email; please don't worry about committing to anything. We are all here in our free time to experiment and possibly have fun in the process, no strings attached 😜

bsakaguchi commented

2026-10-15 12:48:43 +00:00

Author

Owner

@salty2011 commented on GitHub (Jun 23, 2025):

Completely agree with @ABeltramo were wanting to grow the community of contributors.

Im also going to be reading through the docker mods etc as hadn't heard of this

@salty2011 commented on GitHub (Jun 23, 2025): Completely agree with @ABeltramo were wanting to grow the community of contributors. Im also going to be reading through the docker mods etc as hadn't heard of this

bsakaguchi commented

2026-10-15 12:48:43 +00:00

Author

Owner

@shawly commented on GitHub (Jun 24, 2025):

The functionality of linuxserver/docker-mods is quite simple, an lsio mod is basically a collection of scripts in the file structure required by s6-overlay, built into a simple docker image for packaging, here is a simple example: https://github.com/linuxserver/docker-mods/tree/plex-absolute-hama

The linuxserver base images contain the necessary scripts to pull the "mod image" requested and extract it into the root of the container. Of course it is a little more complex but you get the gist of it I think.

With s6-overlay we would enforce a really solid structure for init scripts that can be built upon which will making mods also much easier.

We don't have anything stable (hence the :edge tag), and I don't mind possibly breaking something if we end up with a more robust and easily extensible solution. Also, nothing is forced to users; everyone is free to use any image!

If you are fine with this then I would definitely be up to the task, I guess this will take a while to migrate everything to s6, but I'd love to contribute!

@shawly commented on GitHub (Jun 24, 2025): The functionality of `linuxserver/docker-mods` is quite simple, an lsio mod is basically a collection of scripts in the file structure required by s6-overlay, built into a simple docker image for packaging, here is a simple example: https://github.com/linuxserver/docker-mods/tree/plex-absolute-hama The linuxserver base images [contain the necessary scripts](https://github.com/linuxserver/docker-baseimage-ubuntu/blob/b735660e16d30360504c49fbfe0536e9b69ab1f7/Dockerfile#L70C18-L70C115) to pull the "mod image" requested and extract it into the root of the container. Of course it is a [little more complex](https://github.com/linuxserver/docker-mods/blob/mod-scripts/docker-mods.v3) but you get the gist of it I think. With s6-overlay we would enforce a really solid structure for init scripts that can be built upon which will making mods also much easier. > We don't have anything stable (hence the :edge tag), and I don't mind possibly breaking something if we end up with a more robust and easily extensible solution. Also, nothing is forced to users; everyone is free to use any image! If you are fine with this then I would definitely be up to the task, I guess this will take a while to migrate everything to s6, but I'd love to contribute!

bsakaguchi commented

2026-10-15 12:48:43 +00:00

Author

Owner

@ABeltramo commented on GitHub (Jun 24, 2025):

Welcome on board then! 🚀

Sounds all very good, really curious to see how this will evolve! Feel free to ping me here or on our Discord server if you need any help or even just to discuss the details.

@ABeltramo commented on GitHub (Jun 24, 2025): Welcome on board then! 🚀 Sounds all very good, really curious to see how this will evolve! Feel free to ping me here or on our Discord server if you need any help or even just to discuss the details.

bsakaguchi commented

2026-10-15 12:48:43 +00:00

Author

Owner

@salty2011 commented on GitHub (Jun 25, 2025):

Nice, I can see some of this being use for who some idea's I have in the pipeline for wolf manager..... we'll maybe after its stable and people can launch without many issue :)

But on another note in answer to your original question tldr version

WolfManager will handle artwork fetching and presenting it out for Wolf to use... earlier versions of WolfManager prior to the code rebase did have an early implementation of fetching artwork from SteamGridDB (and some of that code is still in the current release ive just disabled it for now)
Protontricks / Compatibility layer etc: Raise a good point, neither project handle it well today or at all.. But I think this is something WolfManager should be able to sort out as well.

The goals of WolfManager are to

Easy configuration of Wolf
Manage updates of containers
User configuration along with user state management
Device Pairing
Manage libraries

For the libraries I was thinking of treating it more like a plugin system that could interface with WolfManager so that way could be extensible to support more libraries, the community would just need to write a plugin to add the support.

Conceptually taking this further I actually was thinking

Treat containers as a runtime environment, so this would mean you have say a steam container thats just steam
A Library plugin would comprise of, user management (ie steam account), runtime environment , download handling. Mods (ie proton tricks etc)
WolfManager would have a set of common interfaces, like Shared library location, container image downloading, launch configuration

Tbh this isnt well described here, and I need to diagram it up to show my thinking, prolly will better explain things. here is something quick and dirty... so needs allot more work, but conceptually the library plugin would to enable steam, epic,gog or even RomM (emulation library).

@salty2011 commented on GitHub (Jun 25, 2025): Nice, I can see some of this being use for who some idea's I have in the pipeline for wolf manager..... we'll maybe after its stable and people can launch without many issue :) But on another note in answer to your original question tldr version - WolfManager will handle artwork fetching and presenting it out for Wolf to use... earlier versions of WolfManager prior to the code rebase did have an early implementation of fetching artwork from SteamGridDB (and some of that code is still in the current release ive just disabled it for now) - Protontricks / Compatibility layer etc: Raise a good point, neither project handle it well today or at all.. But I think this is something WolfManager should be able to sort out as well. The goals of WolfManager are to - Easy configuration of Wolf - Manage updates of containers - User configuration along with user state management - Device Pairing - Manage libraries For the libraries I was thinking of treating it more like a plugin system that could interface with WolfManager so that way could be extensible to support more libraries, the community would just need to write a plugin to add the support. Conceptually taking this further I actually was thinking - Treat containers as a runtime environment, so this would mean you have say a steam container thats just steam - A Library plugin would comprise of, user management (ie steam account), runtime environment , download handling. Mods (ie proton tricks etc) - WolfManager would have a set of common interfaces, like Shared library location, container image downloading, launch configuration Tbh this isnt well described here, and I need to diagram it up to show my thinking, prolly will better explain things. here is something quick and dirty... so needs allot more work, but conceptually the library plugin would to enable steam, epic,gog or even RomM (emulation library). <img width="837" alt="Image" src="https://github.com/user-attachments/assets/68fa1c83-7f4f-418a-bd2b-ce61cae91508" />

bsakaguchi commented

2026-10-15 12:48:44 +00:00

Author

Owner

@flier268 commented on GitHub (Sep 21, 2025):

I'm not sure if this is a good approach. Perhaps supporting some kind of script would be a good approach.
For example:

[[apps]]
title = 'Steam with lsfg-vk'
init_scripts = [{"id"= "step1", scripts = ["echo installing lsfg-vk","wget https://github.com/PancakeTAS/lsfg-vk/releases/download/v1.0.0/lsfg-vk-1.0.0.x86_64.deb", "apt install .lsfg-vk-1.0.0.x86_64.deb","rm lsfg-vk-1.0.0.x86_64.deb", "echo done." ] }]

After executing Step 1, save something in the repository so that the startup scripts will skip this operation unless the image is upgraded

@flier268 commented on GitHub (Sep 21, 2025): I'm not sure if this is a good approach. Perhaps supporting some kind of script would be a good approach. For example: ```toml [[apps]] title = 'Steam with lsfg-vk' init_scripts = [{"id"= "step1", scripts = ["echo installing lsfg-vk","wget https://github.com/PancakeTAS/lsfg-vk/releases/download/v1.0.0/lsfg-vk-1.0.0.x86_64.deb", "apt install .lsfg-vk-1.0.0.x86_64.deb","rm lsfg-vk-1.0.0.x86_64.deb", "echo done." ] }] ``` After executing Step 1, save something in the repository so that the startup scripts will skip this operation unless the image is upgraded

bsakaguchi commented

2026-10-15 12:48:44 +00:00

Author

Owner

@shawly commented on GitHub (Sep 22, 2025):

I've been slowly migrating the base images in the last weekends but I haven't had as much time as I had hoped. I also had to give up trying out game streaming since my NVIDIA SHIELD TV has massive network issues which I haven't yet been able to solve.

After executing Step 1, save something in the repository so that the startup scripts will skip this operation unless the image is upgraded

Won't work since the changes are written to the container's filesystem and not to the image and the container is thrown away after it stopped. Wolf would need to keep the container around, which is possible if it were started without the --rm arg, but that would make things a lot more error prone and more complicated to implement on the Wolf-Server side, since it would need to check if the config.toml has changed and then re-create the container if it were the case, otherwise start the container.

Anyway, I think init-scripts and stuff that download and install packages at runtime are not ideal, since every script that takes a lot of time to execute will slowdown startup time of a container. Imagine having 5-10 plugins, all which need to install packages and configurations. Also if anything fails the container won't come up and you'd wait possibly minutes just to find out your current configuration is broken. I already find the startup time to be quite long and we should think about keeping it as short as possible.

Library layer idea

I think the "library layer" like @salty2011 suggested is an idea that is worth pursuing.

One idea I had would be to provide the "plugins" as archives extracted from docker layers as this would make the plugin build reproducible and wouldn't require the users to build stuff on their machines, we can just use GitHub Workflows for that.

A gow plugin repo would need to follow a certain kind of structure like this:

gow-plugin-foo-bar/
|____Dockerfile    # for building the plugin layer
|____.github
| |____workflows
| | |____build-plugin.yml  # a GitHub workflow that builds the image
|____rootfs            # for additional files supplied by the plugin (e.g. s6 services and scripts)
| |____etc
| | |____s6-overlay
| | | |____s6-rc.d
| | | | |____init-example
| | | | | |____up
| | | | | |____type
| | | | | |____dependencies.d
| | | | | | |____init-base-end
| | | | | |____run
| | | | |____user
| | | | | |____init-example
| | | | | |____svc-example
| | | | |____svc-example
| | | | | |____up
| | | | | |____type
| | | | | |____dependencies.d
| | | | | | |____init-example
| | | | | |____run
|____gow-plugin-manifest.json   # a manifest that declares dependencies, incompatibilities, name, version etc. similar to a package.json maybe it makes sense to even use some existing package manager for this?

For this we could provide a Github template repo so every plugin dev works on the same base.
This template repo would use a GitHub Workflow which essentially does roughly the following:

Build the plugin docker image (ghcr.io/shawly/gow-plugin-foo-bar:edge) that is based on a gow image (e.g. ghcr.io/games-on-whales/steam:edge)
Save the built image as tarball
Extract the delta of layers between the base image and the plugin image (working script for that https://github.com/shawly/gow-plugin-foo-bar/blob/main/.github/workflows/extract_delta_layers.py)
Create a release (e.g. force push an edge tag to git which will be used for edge versions)
Create a .tar.gz of all layers and then add them to the release as assets

Now with these layers we can effectively use the Docker ADD directive to rebuild an image with our plugin layers, but without the necessary overhead, making it somewhat fast as we only need to download the layers and then extract them.

FROM ghcr.io/games-on-whales/steam:edge

# gow-plugin-foo-bar@edge
ADD gow-plugin-foo-bar/layers/01_blobs_sha256_hashbla.tar
ADD gow-plugin-foo-bar/layers/02_blobs_sha256_hashbla.tar
ADD gow-plugin-foo-bar/layers/03_blobs_sha256_hashbla.tar
ENV FOO=1  # extracted from manifest maybe?

# gow-plugin-baz-qux@edge
ADD gow-plugin-baz-qux/layers/01_blobs_sha256_hashbla.tar
ADD gow-plugin-baz-qux/layers/02_blobs_sha256_hashbla.tar

If a plugin would need to supply ENV vars we could add that to the gow-plugin-manifest.json so the final Dockerfile also gets them

Since the Docker ADD directive also extracts local tars we don't need to care about extracting the layers ourselves. Which also makes sure that nothing will mess with the file permissions and ownerships.
The order of plugins would then also matter since plugins can override files of previous plugins. We could imagine this being similar to the ModOrganizer2 for Skyrim. With this approach people could also build compatibility plugins that fix issues between two plugins for example. I imagine that Wolf-Manager would handle the ordering of plugins and the adding of them.

Wolf would then handle downloading, building and updating the image with the selected plugins. Or when the app image is updated for example.

I already mocked up an example plugin: https://github.com/shawly/gow-plugin-foo-bar/tree/main

What do you think about this approach?

@shawly commented on GitHub (Sep 22, 2025): I've been slowly migrating the base images in the last weekends but I haven't had as much time as I had hoped. I also had to give up trying out game streaming since my NVIDIA SHIELD TV has massive network issues which I haven't yet been able to solve. > After executing Step 1, save something in the repository so that the startup scripts will skip this operation unless the image is upgraded Won't work since the changes are written to the container's filesystem and not to the image and the container is thrown away after it stopped. Wolf would need to keep the container around, which is possible if it were started without the --rm arg, but that would make things a lot more error prone and more complicated to implement on the Wolf-Server side, since it would need to check if the config.toml has changed and then re-create the container if it were the case, otherwise start the container. Anyway, I think init-scripts and stuff that download and install packages at runtime are not ideal, since every script that takes a lot of time to execute will slowdown startup time of a container. Imagine having 5-10 plugins, all which need to install packages and configurations. Also if anything fails the container won't come up and you'd wait possibly minutes just to find out your current configuration is broken. I already find the startup time to be quite long and we should think about keeping it as short as possible. ## Library layer idea I think the "library layer" like @salty2011 suggested is an idea that is worth pursuing. One idea I had would be to provide the "plugins" as archives extracted from docker layers as this would make the plugin build reproducible and wouldn't require the users to build stuff on their machines, we can just use GitHub Workflows for that. A gow plugin repo would need to follow a certain kind of structure like this: ``` gow-plugin-foo-bar/ |____Dockerfile # for building the plugin layer |____.github | |____workflows | | |____build-plugin.yml # a GitHub workflow that builds the image |____rootfs # for additional files supplied by the plugin (e.g. s6 services and scripts) | |____etc | | |____s6-overlay | | | |____s6-rc.d | | | | |____init-example | | | | | |____up | | | | | |____type | | | | | |____dependencies.d | | | | | | |____init-base-end | | | | | |____run | | | | |____user | | | | | |____init-example | | | | | |____svc-example | | | | |____svc-example | | | | | |____up | | | | | |____type | | | | | |____dependencies.d | | | | | | |____init-example | | | | | |____run |____gow-plugin-manifest.json # a manifest that declares dependencies, incompatibilities, name, version etc. similar to a package.json maybe it makes sense to even use some existing package manager for this? ``` For this we could provide a Github template repo so every plugin dev works on the same base. This template repo would use a GitHub Workflow which essentially does roughly the following: 1. Build the plugin docker image (ghcr.io/shawly/gow-plugin-foo-bar:edge) that is based on a gow image (e.g. ghcr.io/games-on-whales/steam:edge) 2. Save the built image as tarball 3. Extract the **delta** of layers between the base image and the plugin image (working script for that https://github.com/shawly/gow-plugin-foo-bar/blob/main/.github/workflows/extract_delta_layers.py) 4. Create a release (e.g. force push an `edge` tag to git which will be used for edge versions) 5. Create a .tar.gz of all layers and then add them to the release as assets Now with these layers we can effectively use the Docker ADD directive to rebuild an image with our plugin layers, but without the necessary overhead, making it somewhat fast as we only need to download the layers and then extract them. ``` FROM ghcr.io/games-on-whales/steam:edge # gow-plugin-foo-bar@edge ADD gow-plugin-foo-bar/layers/01_blobs_sha256_hashbla.tar ADD gow-plugin-foo-bar/layers/02_blobs_sha256_hashbla.tar ADD gow-plugin-foo-bar/layers/03_blobs_sha256_hashbla.tar ENV FOO=1 # extracted from manifest maybe? # gow-plugin-baz-qux@edge ADD gow-plugin-baz-qux/layers/01_blobs_sha256_hashbla.tar ADD gow-plugin-baz-qux/layers/02_blobs_sha256_hashbla.tar ``` If a plugin would need to supply ENV vars we could add that to the gow-plugin-manifest.json so the final Dockerfile also gets them Since the Docker ADD directive also extracts local tars we don't need to care about extracting the layers ourselves. Which also makes sure that nothing will mess with the file permissions and ownerships. The order of plugins would then also matter since plugins can override files of previous plugins. We could imagine this being similar to the ModOrganizer2 for Skyrim. With this approach people could also build compatibility plugins that fix issues between two plugins for example. I imagine that Wolf-Manager would handle the ordering of plugins and the adding of them. Wolf would then handle downloading, building and updating the image with the selected plugins. Or when the app image is updated for example. I already mocked up an example plugin: https://github.com/shawly/gow-plugin-foo-bar/tree/main What do you think about this approach?

bsakaguchi commented

2026-10-15 12:48:44 +00:00

Author

Owner

@salty2011 commented on GitHub (Oct 18, 2025):

hmm interesting, the Library idea I was pitching / working on was to directly integrate with things like steam / gog to download and install games into the shared library location. it would also help track which games belong to a users library. This would then also configure apps into WolfUI.

However conceptually the whole library thing was meaning to be a plugin system for WolfManager so that it could be extended in the ways your describing.

Currently haven't had time to do much with WolfManager, was mostly to trying to clean it up, remove bugs etc before moving to next phase

@salty2011 commented on GitHub (Oct 18, 2025): hmm interesting, the Library idea I was pitching / working on was to directly integrate with things like steam / gog to download and install games into the shared library location. it would also help track which games belong to a users library. This would then also configure apps into WolfUI. However conceptually the whole library thing was meaning to be a plugin system for WolfManager so that it could be extended in the ways your describing. Currently haven't had time to do much with WolfManager, was mostly to trying to clean it up, remove bugs etc before moving to next phase

bsakaguchi referenced this issue

2026-10-15 12:49:20 +00:00

[PR #73] [CLOSED] Minecraft #130

bsakaguchi referenced this issue

2026-10-15 12:49:23 +00:00

[PR #77] [CLOSED] Add minecraft #136

Rows
Columns

[GH-ISSUE #244] Allow users to easily expand images #73

Library layer idea