[MacPorts] #58638: port:youtube-dl : upgrade and performance improvement

[MacPorts]

#58638: port:youtube-dl : upgrade and performance improvement
--------------------------+------------------------
  Reporter:  RJVB         |      Owner:  ryandesign
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:  haspatch
      Port:  youtube-dl   |
--------------------------+------------------------

Comment (by ryandesign):

 Replying to [ticket:58638 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/58638#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS