[vlc-devel] [PATCH 1/2] share: add wrapper script for the YoutubeDL Python module

[Steve Lhomme]

On 2020-09-21 10:36, Marvin Scholz wrote:
> 
> 
> On 21 Sep 2020, at 10:34, Steve Lhomme wrote:
> 
>> On 2020-09-21 10:30, Marvin Scholz wrote:
>>>
>>>
>>> On 21 Sep 2020, at 10:22, Steve Lhomme wrote:
>>>
>>>> On 2020-09-20 20:57, Rémi Denis-Courmont wrote:
>>>>> This script generates a M3U playlist from a given URL, providing a
>>>>> simple serial format that can be read and parsed by another process.
>>>>>
>>>>> There are in principles two other alternative ways to access it:
>>>>>
>>>>> 1) Calling the YoutubeDL module directly in-process through CPython.
>>>>>     This poses a number of problems:
>>>>>     - CPython must be loaded by the main executable. Python modules 
>>>>> will
>>>>>       fail to resolve their CPython symbols otherwise.
>>>>>     - Multiple CPython interpreters are still very immature; GIL 
>>>>> behaves
>>>>>       weirdly. CPython is really not meant for multithread.
>>>>>     - The GIL prevents concurrent uses (that's the whole point of it).
>>>>>     - CPython network I/O cannot be interrupted by VLC 
>>>>> interruptions, so
>>>>>       the calling thread may get stuck inside CPython.
>>>>>     - A build-time dependency on CPython is added.
>>>>>
>>>>> 2) Parsing the output of the youtube-dl program. This is what MPV 
>>>>> does.
>>>>>     But this requires a whole new parser for the Python syntax.
>>>>>
>>>>> With a custom Python script, we can decide on the serialisation format
>>>>> that most suits the usage.
>>>>> ---
>>>>>   share/Makefile.am     |   2 +
>>>>>   share/ytdl-extract.py | 103 
>>>>> ++++++++++++++++++++++++++++++++++++++++++
>>>>>   2 files changed, 105 insertions(+)
>>>>>   create mode 100755 share/ytdl-extract.py
>>>>>
>>>>> diff --git a/share/Makefile.am b/share/Makefile.am
>>>>> index 2373ffbe91..8a92f04360 100644
>>>>> --- a/share/Makefile.am
>>>>> +++ b/share/Makefile.am
>>>>> @@ -49,6 +49,8 @@ nobase_dist_pkgdata_SCRIPTS = \
>>>>>       utils/audio-vlc-default.sh \
>>>>>       utils/video-vlc-default.sh \
>>>>>       $(NULL)
>>>>> +
>>>>> +dist_pkgdata_SCRIPTS = ytdl-extract.py
>>>>>   endif
>>>>>    EXTRA_DIST += \
>>>>> diff --git a/share/ytdl-extract.py b/share/ytdl-extract.py
>>>>> new file mode 100755
>>>>> index 0000000000..2d784c5090
>>>>> --- /dev/null
>>>>> +++ b/share/ytdl-extract.py
>>>>> @@ -0,0 +1,103 @@
>>>>> +#! /usr/bin/python3
>>>>> +#
>>>>> +# Copyright (C) 2020 Rémi Denis-Courmont
>>>>> +#
>>>>> +# This program is free software; you can redistribute it and/or 
>>>>> modify it
>>>>> +# under the terms of the GNU Lesser General Public License as 
>>>>> published by
>>>>> +# the Free Software Foundation; either version 2.1 of the License, or
>>>>> +# (at your option) any later version.
>>>>> +#
>>>>> +# This program is distributed in the hope that it will be useful,
>>>>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>>> +# GNU Lesser General Public License for more details.
>>>>> +#
>>>>> +# You should have received a copy of the GNU Lesser General Public 
>>>>> License
>>>>> +# along with this program; if not, write to the Free Software 
>>>>> Foundation,
>>>>> +# Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, USA.
>>>>> +
>>>>> +import sys
>>>>> +import youtube_dl
>>>>
>>>> How does this work if the import library is not there ? Do we have 
>>>> requirements on the version of the library ? Can we check it in 
>>>> configure.ac ?
>>>
>>> Checking it in configure.ac seems useless as this is about the host 
>>> system, not a build time requirement.
>>> If the library is not there or its the wrong version so API does not 
>>> match, it the script would just fail
>>> which IIUC is handled properly by the access module calling the script.
>>>
>>>> Can it be part of contribs ?
>>>
>>> Could be possible, but IMO out of scope of this patchset.
>>>
>>>> Should we run python with out local environment with our little set 
>>>> of dependencies ?
>>>
>>> Why would you want to do that? I dont really see any benefit doing so 
>>> while possibly
>>> breaking the import.
>>
>> I think it's the opposite. Using the system dependencies might be the 
>> one breaking the version we support.
> 
> Not sure what you mean by "version we support" as we rely on the 
> system-installed
> youtube-dl here. Worst case the API is different and it fails?

If the youtube-dl of the system changes with a different API or way or 
working that we support it breaks the feature in VLC. If we have our 
local version of youtube-dl we don't have this problem.