port:youtube-dl : upgrade and performance improvement

[RJVB (René Bertin)]

This started out when I noticed that youtube-dl is a zipped "script bundle" which means that it has to be inflated and byte-compiled on each and every invocation. That takes a noticeable amount of time, even on a faster machine. Testing shows that startup time becomes roughly 4x shorter when you install the application as a regular, uncompressed set of python scripts, of which bytecode can be cached.

The patch introduces a +unpacked variant which creates such an install. It takes a post-destroot approach, inflating the actual script, in order to ensure that the exact same code will be executed. In-app upgrades are impossible with this kind of install so there is no need to disable them via a hack.

I propose to drop the compulsory use of a MacPorts Python interpreter; the system one does just fine. The proposed +stock variant creates an install that is the pure stock version. I see no hard reason to ban in-app upgrades for such an install (the script will replace itself), leaving a backdoor for people who somehow need the latest versions *now*.

The upgrade to the current version is almost an afterthought :)

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

This started out when I noticed that youtube-dl is a zipped "script bundle" which means that it has to be inflated and byte-compiled on each and every invocation. That takes a noticeable amount of time, even on a faster machine. Testing shows that startup time becomes roughly 4x shorter when you install the application as a regular, uncompressed set of python scripts, of which bytecode can be cached.

I was aware that it is zipped, but I was not aware of the implications you mentioned. Do you know whether the developer of youtube-dl is aware of these implications and if so what his position on this is?

The patch introduces a +unpacked variant which creates such an install. It takes a post-destroot approach, inflating the actual script, in order to ensure that the exact same code will be executed. In-app upgrades are impossible with this kind of install so there is no need to disable them via a hack.

If unpacking the script has the advantages you claim, we should always do so; we should not make it a user choice via a variant.

I propose to drop the compulsory use of a MacPorts Python interpreter; the system one does just fine.

I would say no. Apple has stated that future versions of macOS will not ship with scripting language interpreters. We should move our ports in a direction that will accommodate that change, by ensuring we always use MacPorts scripting language interpreters.

The proposed +stock variant creates an install that is the pure stock version. I see no hard reason to ban in-app upgrades for such an install (the script will replace itself), leaving a backdoor for people who somehow need the latest versions *now*.

I don't want to change the fact that I ban in-app upgrades. We don't want anything other than MacPorts to install files that MacPorts ports install.

The upgrade to the current version is almost an afterthought :)

That should be done separately.

[RJVB (René Bertin)]

I don't know if the developer is aware of the implications of zipping the script but I cannot imagine he is not. The various instructions for building, installing and running do not give the impression he considers that the zipped version is the only way to go.

[ryandesign (Ryan Carsten Schmidt)]

In a91d9d9f82d094567814e8a66d1846c0bd093c90/macports-ports (master):

youtube-dl: Use python portgroup / setup.py

This allows the python files to be compiled at installation time rather
than every time at runtime, making the program launch faster.

Closes: #58638