Why is a static uid required?

My initial thought was so that the whole dataDir folder /var/lib/piwik can be easily restored from a backup, e.g. after a failure that needed a reinstall or on another machine.

In the meantime I learned that actually only a single file, /var/lib/piwik/config/config.ini.php needs to be backed up. It's probably easy enough to fix uid+gid for a single file manually on restores, so I guess it's not that required anymore. Nothing in the code depends on it, I could simply remove the static assignment again.

This is my first nixpkg package, could you tell me more about in which cases and for what purposes it's considered good pratice to use static ids, and in which it isn't?

The most clear-cut use for static uids is if you need to refer to a user before the user/uid mapping is established. Otherwise, you need to make a judgement about the kind of data the daemon generates, whether you'd transfer the data between hosts, whether ownership can be easily fixed up, what the privacy or security implications would be if the data ended up being owned (however transiently) by another user etc.

Relying on static uids to maintain ownership invariants is fragile imo (it won't help if you transfer data to a non-NixOS host, for example). Better to have code that enforces invariants you care about directly.

Now, I don't mean to say you should overthink this but there should be a reason for doing it :)

Thanks alot for that explanation, that was very helpful. :)

I decided to remove the static ids and added a small chown+chmod script in the systemd unit that is executed as root and enforces the right ownership and permissions on startup instead. I figured that's much more beneficial to what I wanted to achieve, keeping things private while allowing an occasional but easy restore/move.

Sounds good to me. If it turns out that a static uid makes more sense, it can always be added later (the other way 'round is a little harder).

I think users.extraGroups.${user} = {} would work as well.

Much more elegant. 😃

Note that "${foo}" could be simplified to foo.

Group is strictly redundant, it defaults to the primary group of User.

Please consider disabling problematic phases instead of listing phases; this is a known source of bugs.

Could just throw this out completely, did learn that all default phases don't do anything like the buildPhase doesn't do anything if there is no Makefile.

Can go innativeBuildInputs.

Consider postPatch; at least in general its nice to allow applying arbitrary patches via override. Specifying a custom patch phase prevents that.

Nit: examples for booleans are usually skipped, it's self-evident.

Note that long-form descriptions may not render very well. You can generate the nixos manual to check whether it'll look okay. You can farm out longer documentation fragments to the manual.

You are right, it renders quite bad.

So it would be ok to include a new manual section like II.Configuration > 22. piwik for that longer part? I was struggeling to find a good place for this, but now I see this long description isn't one.

Note that this will cause install hooks to be skipped (you can run e..g, the post phase hook manually with runHook postInstall).

I understand. I added runHook call for preInstall / postInstall as first / last commands of my installPhase, mirroring the default implementation I found in pkgs/stdenv/generic/setup.sh. From that file I assume there's no better way to overwrite / have a custom installPhase without having to call the hooks by hand, right?

Pretty much. At some point I think it's possible hooks may become implicit, making this a bit more natural.

If you wish, you could add yourself to the list of maintainers.

I thought you had to be part of the NixOS github organization to be a maintainer. 😅

Not at all. It basically means you care about the package, lets other's know to ping you if there are questions or whatever.

Might want to revert this line :D

It was actually intentional, as it is a web application for web analytics, but I admit it sounds really weird in english, adds nothing much and probably irritates the reader more than clarifies stuff. 😆 Thanks!

Yeah, I could see that.