platformdirs.user_runtime_dir() currently yields /run/user/0/… for root on Unix. While not strictly false, this is a rather uncommon result; for root I'd rather expect just /run/….
To understand the issue we must take a step back and think about the runtime dir in the XDG basedir specs:
The lifetime of the [runtime] directory MUST be bound to the user being logged in.
For unprivileged users this makes total sense, because users not being logged in should not have any active processes, thus no runtime dir is needed. However, root is different: Software running as root is often intentionally NOT bound to root being logged in - in many systems root can't login at all. This is due to root's special role in Unix and a major difference to any other user. If we strictly follow the XDG basedir spec, /run/user/0/ must not exist if root isn't logged in - i.e. in most cases. Yet is software running and requiring a location for their runtime data. This doesn't mean that there might not indeed be software whose lifetime is bound to root being logged in - but that's the exception rather than the rule.
AFAIK platformdirs doesn't address root's special role in Unix towards the runtime dir right now, but it should.
Therefore I'd like to put root's special role and how to deal with it up for discussion.
My opinion on this is, that since there might indeed be cases in which /run/user/0/… is the "true" answer, platformdirs should leave platformdirs.user_runtime_dir() unchanged, but add a new platformdirs.site_runtime_dir() method instead. root's special role should be documented accordingly and we should leave it up to developers to decide whether the lifetime of their software is bound to root being logged in or not.
As additional feature it might be helpful to add a global switch (disabled by default) which basically redirects calls to platformdirs.user_*_dir() to their platformdirs.site_*_dir() equivalent (i.e. not just for user_runtime_dir(), but config, cache, state, … too) for root unless stated otherwise (i.e. add a option to each method next to the global switch).
platformdirs.user_runtime_dir()currently yields/run/user/0/…for root on Unix. While not strictly false, this is a rather uncommon result; for root I'd rather expect just/run/….To understand the issue we must take a step back and think about the runtime dir in the XDG basedir specs:
For unprivileged users this makes total sense, because users not being logged in should not have any active processes, thus no runtime dir is needed. However, root is different: Software running as root is often intentionally NOT bound to root being logged in - in many systems root can't login at all. This is due to root's special role in Unix and a major difference to any other user. If we strictly follow the XDG basedir spec,
/run/user/0/must not exist if root isn't logged in - i.e. in most cases. Yet is software running and requiring a location for their runtime data. This doesn't mean that there might not indeed be software whose lifetime is bound to root being logged in - but that's the exception rather than the rule.AFAIK
platformdirsdoesn't address root's special role in Unix towards the runtime dir right now, but it should.Therefore I'd like to put root's special role and how to deal with it up for discussion.
My opinion on this is, that since there might indeed be cases in which
/run/user/0/…is the "true" answer,platformdirsshould leaveplatformdirs.user_runtime_dir()unchanged, but add a newplatformdirs.site_runtime_dir()method instead. root's special role should be documented accordingly and we should leave it up to developers to decide whether the lifetime of their software is bound to root being logged in or not.As additional feature it might be helpful to add a global switch (disabled by default) which basically redirects calls to
platformdirs.user_*_dir()to theirplatformdirs.site_*_dir()equivalent (i.e. not just foruser_runtime_dir(), but config, cache, state, … too) for root unless stated otherwise (i.e. add a option to each method next to the global switch).Cc: @ThomasWaldmann