Document that the module's files option does env substitution

[frantisekhanzlikbl]

Currently, neither the readme nor the option docs mention that services.minecraft-servers.servers.<name>.files performs environment substitution.

I just got bitten by this when working with binaries that were getting mysteriously corrupted, and the module mutating them was not something that I expected.

The ideal case scenario is IMHO that this is disabled by default and opt-in on each file, or at least opt-able out of, but it should really be documented. I can make a PR for either if it helps. 🙂

[Infinidoge]

It's technically documented under the environmentFile option, however I do agree that it should be documented under files as well. Making it toggleable should be pretty straight forward too, but would likely need some changes to the mkFiles script. Feel free to open PRs if you have the time :)

[frantisekhanzlikbl]

hi, sorry for not replying sooner. I kept thinking I'll find time for this somewhen, but I'm starting to see I won't be able to anytime soon. on top of that, I'm somewhat considering moving my infra over from systemd to nomad. while NixOS modules are superior in many ways, I'm starting to feel the need for a more flexible orchestrator, and would also prefer to spend less time worrying about every other NixOS service being completely unsandboxed. :)

[YaroKasear]

I just found this without seeing this bug report.

This issue of doing env substitution blindly makes the files option unusable for setting up mods. And since symlinks puts a symlink directly to the Nix Store, it doesn't look like there's a proper way to declaratively install mods, at least not the way the README suggests.

[Infinidoge]

The symlinks option is the proper way to declaratively install mods. Mods are binaries, so symlinking them to the nix store is perfectly fine and generally preferable, as it reduces on the space cost of copying files.

I do agree that the files option mangling jar files is improper behavior though, and should be fixed.

[YaroKasear]

The symlinks option is the proper way to declaratively install mods. Mods are binaries, so symlinking them to the nix store is perfectly fine and generally preferable, as it reduces on the space cost of copying files.

The issue with this is that it's a symlink to the Nix Store and Paper (And probably other server codebases.) likes to create the plugin configs in the same directory as the jars... which it can't do since the Nix Store is read-only. This causes Paper to bail with a "read-only file system" because it can't write to the plugins directory symlink makes.

Unless there's some other way to get this to work? Is there a setting I overlooked where Paper can create plugin configs outside the plugins directory which is a symlink to the Nix Store?

[Infinidoge]

<Tired opinion (not because of you but because I've dealt with this before)>
As far as I am concerned, this is because Paper is bad. Paper, and other plugin-centered projects, are the only ecosystem I've seen that feels like it has any dominion over the folder dedicated to putting binaries from the user. No other modloader does this. The fact that a mod port of a plugin did this (LuckPerms) frustrated me to the point where I just found an alternative instead.
</Tired opinion>

The proper way to work around this is to make symlinks individually in the manner you did with the files option, as opposed to symlinking directly to the mods folder. (I.e.,use "mods/mod.jar" = ...; instead of mods = pkgs.symlinkJoin ...;) There isn't a better option because Paper tries to write to a directory it has no business writing to. You can, at minimum, do this a bit easier with mapAttrs.

[YaroKasear]

Hmm, that's not a perspective I thought of. I honestly don't think it's a problem, but that's why it's opinion, I suppose.

What server do you recommend?

[Infinidoge]

I exclusively use mod loaders and not plugins, so the use case is a bit different. For my part, I use Fabric and Quilt on all of my servers, including vanilla-compatible ones. Forge is also a possibility for highly modded ones, but since that isn't currently packaged (see #15), I just stick with the textiles.

[Misterio77]

Will be fixed by #116