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

Previous Next

Full log

Message #14 received at 69692 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Skyler Ferris <skyvine <at> protonmail.com>
Cc: 69692 <at> debbugs.gnu.org
Subject: Re: [bug#69692] [PATCH] gnu: Add home-jellyfin-mpv-shim-service-type.
Date: Thu, 22 Aug 2024 07:57:28 -0700

Hi Skyler,

Did you have any other thoughts or feedback on this patch?  I’d 
like to see this in Guix proper.

Thanks,

 — Ian

Ian Eure <ian <at> retrospec.tv> writes:

> Hi Skyler,
>
> Sorry for the extremely delayed response here.
>
> Skyler Ferris <skyvine <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.