[bug#61117] Update svtplay-dl to 4.18

Hello,

I've attached a patch to upgrade svtplay-dl from 4.17 to 4.18. I've also moved 
ffmpeg form inputs to propagated-inputs as it's needed while the program is 
running to merge two files, not while building.

Thanks,
Jessica.
  

Jessica,

Jessica Tallon 写道：
> I've attached a patch to upgrade svtplay-dl from 4.17 to 4.18.

Thanks!

> I've also moved ffmpeg form inputs to propagated-inputs

Please avoid propagation whenever possible; it breaks all kinds of 
nice things.

Propagating A from B means that Guix will effectively ‘install’ A 
alongside B when the user installs only B.  Or how classical 
package managers bluntly handle ‘dependencies’.  Not good!

Here's what I'd do instead [untested]:

    (arguments
     (list #:phases
           #~(modify-phases %standard-phases
               (add-after 'wrap 'wrap-harder
                 (lambda* (#:key inputs outputs 
                 #:allow-other-keys)
                   (wrap-script (string-append (assoc-ref outputs 
                   "out")
                                               "/bin/svtplay-dl")
                     `("PATH" ":" prefix
                       (,(dirname (search-input-file inputs
                                                     "bin/ffmpeg"))))))))))
    (native-inputs (list guile-3.0))    ; for wrap-script

> it's needed while the program is 
> running to merge two files, not while building.

So 4.17 did not need or use ffmpeg this way?

Otherwise, put each unrelated changes into a separate commit: one 
to improve the ffmpeg situation, and one to update svtplay-dl. 
You can send multiple related commits as one patch series to one 
bug number, though.

Kind regards,

T G-R
  

Tobias Geerinckx-Rice via Guix-patches via 写道：
>                 (lambda* (#:key inputs outputs
>                 #:allow-other-keys)           ^

Dunno why mu4e added a hard newline here.  There shouldn't be one.

Kind regards,

T G-R
  

Tobias Geerinckx-Rice via Guix-patches via 写道：
>                   (wrap-script (string-append (assoc-ref outputs
>                   "out") 
>                   ^

And here.  All the others are good.  Sorry for the mess.

Kind regards,

T G-R
  

Thanks again for working on this package!

On Sat, Jan 28, 2023 at 01:33:44PM +0100, Tobias Geerinckx-Rice via Guix-patches via wrote:
> > I've also moved ffmpeg form inputs to propagated-inputs
> 
> Please avoid propagation whenever possible; it breaks all kinds of nice
> things.

I'm here to express my weak preference for dynamically binding FFmpeg in
use cases like this one.

That means, I prefer if packages like svtplay-dl do not depend on FFmpeg
at all, but rather expect the user to install FFmpeg alongside them.

I prefer this because I use a custom FFmpeg professionally as a video
engineer, and it's easier to use it with Guix packages if the dependency
is resolved at run-time rather than at build-time.

I'd expect that many people like me also use a variety of custom FFmpeg
builds for different use cases.

Like I said, it's a weak preference. And I probably wouldn't use
svtplay-dl at work in the US, although I do use youtube-dl / yt-dlp. Let
me know what you think.
  

Leo Famulari <leo@famulari.name> writes:

> Thanks again for working on this package!
>
> On Sat, Jan 28, 2023 at 01:33:44PM +0100, Tobias Geerinckx-Rice via Guix-patches via wrote:
>> > I've also moved ffmpeg form inputs to propagated-inputs
>> 
>> Please avoid propagation whenever possible; it breaks all kinds of nice
>> things.
>
> I'm here to express my weak preference for dynamically binding FFmpeg in
> use cases like this one.
>
> That means, I prefer if packages like svtplay-dl do not depend on FFmpeg
> at all, but rather expect the user to install FFmpeg alongside them.
>
> I prefer this because I use a custom FFmpeg professionally as a video
> engineer, and it's easier to use it with Guix packages if the dependency
> is resolved at run-time rather than at build-time.
>
> I'd expect that many people like me also use a variety of custom FFmpeg
> builds for different use cases.
>
> Like I said, it's a weak preference. And I probably wouldn't use
> svtplay-dl at work in the US, although I do use youtube-dl / yt-dlp. Let
> me know what you think.

Hello,

Thanks for sharing your experiance, especially as a professional video
engineer :)

I think I have a mild opinion for having it bring in ffmpeg, this is
mostly for three reasons:

- There isn't a good way to communicate to users that they might wish to
  pull in ffmpeg.
  
- svtplay-dl will download both audio and video parts and then realise
  it doesn't have ffmpeg and will give up producing a warning. This
  leaves it up to the user to fix, while a merging both files is a
  simple job it often has me searching through a manual as I'm not well
  versed in ffmpeg or similar.

- I like it when things work consistantly (if x version of svtplay-dl
  works a specific way on my machine, it should on another machine, not
  dependent on my profile)

My preference is mild though, let me know what you think!

Thanks,
Jessica.
  

On Sun, Mar 05, 2023 at 09:15:14PM +0100, Jessica Tallon wrote:
> I think I have a mild opinion for having it bring in ffmpeg, this is
> mostly for three reasons:
> 
> - There isn't a good way to communicate to users that they might wish to
>   pull in ffmpeg.
>   
> - svtplay-dl will download both audio and video parts and then realise
>   it doesn't have ffmpeg and will give up producing a warning. This
>   leaves it up to the user to fix, while a merging both files is a
>   simple job it often has me searching through a manual as I'm not well
>   versed in ffmpeg or similar.
> 
> - I like it when things work consistantly (if x version of svtplay-dl
>   works a specific way on my machine, it should on another machine, not
>   dependent on my profile)
> 
> My preference is mild though, let me know what you think!

I think you should go with your method!