[bug#69692] [PATCH] gnu: Add home-jellyfin-mpv-shim-service-type.

[Ian Eure]

Hi Skyler,

Sorry for the extremely delayed response here.

Skyler Ferris <skyvine@protonmail.com> writes:

> Hi Ian,
>
> I don't have the setup required to try running this service but 
> 2 things stand out to me when reading through it.
>
> On 3/9/24 21:24, Ian Eure wrote:
>
>  +To enable, add this to your home services:
> +
> +@lisp
> +(service home-jellyfin-mpv-shim-service-type #f)
> +@end lisp
>
> You can add a default-value field to the service definition like 
> so:
>
> (define-public home-jellyfin-mpv-shim-service-type
>   (service-type
>    (name 'home-jellyfin-mpv-shim)
>    (default-value #f)
>    (extensions (list (service-extension 
>    home-shepherd-service-type
>                                         jellyfin-mpv-shim-shepherd-service)
>                      ;; Ensure 'home-x11-service-type' is 
>                      instantiated so we
>                      ;; can depend on the Shepherd 'x11-display' 
>                      service.
>                      (service-extension home-x11-service-type
>                                         (const #t))))
>    (description "Run Jellyfin MPV Shim.")))
> Then, users can simply use (service 
> home-jellyfish-mpv-shim-service-type) without having to specify 
> #f manually And if the
> service ever changes in the future and this value becomes useful 
> then you can provide a reasonable default without requiring
> users to change their 
> code. (https://guix.gnu.org/manual/en/html_node/Service-Reference.html)

Thank you for the suggestion, I’ll incorporate it and send a 
revised patch after we’re in agreement on the launch behavior.

>  +
> +The service only starts if @code{jellyfin-mpv-shim} has been 
> configured with a remote server and credentials.  This must be 
> done manually, by launching @code{jellyfin-mpv-shim}.  After 
> configuring the server, the service will start automatically 
> when you log in.
>
> Would it make sense to launch this program automatically if it 
> is not configured?

I don’t think it would.  When it launches in an unconfigured 
state, you get a very generic "Server Configuration" window, with 
no icon or indication what server you’re configuring, or what for. 
It makes perfect sense if you run the program and that window 
appears, and not much sense at all if it just happens when you log 
in.


> Presumably if someone adds the service then they want to 
> configure a server.

Agreed.  However, configuring the server is a manual action, and 
it doesn’t feel burdensome to manually run the program to do it. 
There isn’t a good way to configure the remote server 
declaratively, since this process involves exchanging a username 
and password for an authentication token, which must be done over 
the network.  You probably wouldn’t want to commit your auth token 
to a repo containing your home configuration, and Guix has no 
facility for securely handling things like this.  So it has to be 
done by hand.


> The value passed to the service could be used to specify whether 
> or not the program should automatically launch so that users who 
> do not want this behavior can disable it (note that if you 
> decide to implement this then the configuration value should be 
> an instance of a new structure defined to store configuration 
> for this service, not a simple boolean; again, this makes things 
> easier in the future so that if you want to add more fields 
> pre-existing code will still work).

Making auto-launch configurable doesn’t seem like a good idea to 
me.  It would only ever apply to the very first launch, and 
wouldn’t significantly change the bounds of the problem.  If the 
default is to launch unconfigured, you get the confusing behavior 
I want to avoid.  If the default is to not launch unconfigured, I 
don’t think anyone would ever change that setting -- it’s be much 
easier to launch the program than to change the setting and `guix 
home reconfigure'.

Thanks,

 — Ian