Under new management
dirkf opened this issue · 173 comments
Thanks to @rg3 who created this program the project has a new maintainer.
Also, many thanks to @dstftw and @remitamine for holding the fort over the last several years.
I hope that we'll be able to make a new release soon and subsequently keep the program more up-to-date than has been the case for the last few months.
The project has a fork https://github.com/yt-dlp/yt-dlp that offers a lot of extra functions but demands an up-to-date Python version. This project will continue to target Python version 2.6, 2.7, or 3.2+, at least until no-one complains about 2.6 compatibility.
PRs are very welcome, although there is a significant back-log to be handled. Back-ports of yt-dlp features are also welcome.
Finally, I'd encourage anyone else who is interested in sharing maintenance duties to establish a track record and make themselves known. We want to keep this popular project alive with a community of future maintainers.
Supporting defunct versions of Python seems like a great way to handicap the project and a total waste of time.
This repository should just become yt-dlp tbh
this is ridiculous. Python 2 is dead
This repository should just become yt-dlp tbh
By now, yt-dlp has accumulated various incompatibilities with youtube-dl and it is no longer a drop-in replacement for many users. So youtube-dl can't just "become yt-dlp". Since I do not intend to revert these changes, it is best that both projects co-exist.
If you like to use yt-dlp, use it. And if you prefer youtube-dl, use this. It is a waste of everyone's time to post issues/comments asking for either project to "become" the other
fyi python 2 reached EOL 2 years ago, before windows 7 did.
This repository should just become yt-dlp tbh
By now, yt-dlp has accumulated various incompatibilities with youtube-dl and it is no longer a drop-in replacement for many users. So youtube-dl can't just "become yt-dlp". Since I do not intend to revert these changes, it is best that both projects co-exist.
If you like to use yt-dlp, use it. And if you prefer youtube-dl, use this. It is a waste of everyone's time to post issues/comments asking for either project to "become" the other
fair enough! Consider mentioning dlp in the readme though?
@Twangist and supporters, please direct your Python 3.7+ enthusiasm to the yt-dlp project, as @pukkandan says.
No-one would bother maintaining two versions of a program if there wasn't a good reason. There are still applications where older Python versions have to be supported: among the known cases are those where that's all the platform offers, and where yt-dl is being embedded in a larger chunk of Python 2 code that no-one is going to port.
This project has already established a compatibility library that largely allows you to code for Python 3 while remaining compatible with Python 2, by using the library's compat_xxx types and avoiding novel syntax elements (nonlocal, yield from, etc), for which there are known work-arounds. With this infrastructure, and provided that yt-dl and yt-dlp continue to support the same extractor API and library functions we can avoid wasted effort on either side.
The project Readme should definitely be updated, in due course, as @boehs suggests.
#30568 (comment) :
The project has a fork https://github.com/yt-dlp that offers a lot of extra functions
Back-ports of yt-dlp features are also welcome.
#30568 (comment)
This repository should just become yt-dlp tbh
Wouldn't merging the two projects be a better use of resources
compared to the overhead/redundancy of maintaining two separate projects ?
Essentially #30568 (comment) said all that needed to be said. But...
Understandably, yt-dlp wants to be able to rely on supported Python versions (and 3.6), which means that we need to keep yt-dl up-to-date to address the cases I described above that can't practically use those versions, desirable as it might be.
For people concerned that Python 2 is a couple of years beyond EOL, one case that I support could survive until 2038, or the end of DVB-T2 broadcasting if that comes sooner. That's the timescale of deployed embedded applications, a very different world from 'What version is Chrome today?' on your personal computing device.
Maybe some future Python version supported by yt-dlp will diverge so far that common development becomes impractical. This isn't the case now.
Appreciate the openness, @dirkf. I personally wasn't aware that one of youtube-dl's goals was Python 2 compatibility so thanks for clearing that up for us.
I am not and will not ever advocate for projects closely mirroring each other. But, in case that's a useful user feedback for you: my main reason for moving to yt-dlp was (a) SponsorBlock API support and (b) external downloaders. If these sound like an interesting thing to support for you then I believe others would love to see them implemented as well. If not, the project is still super valuable in its own right.
Thanks for the update. It's appreciated.
Wouldn't it be better to either release an LTS or to set a date when support for everything below 3.6 is dropped.
Motivating people to stay on EOL versions of Python carries a lot of security risks, not just for this project but also for projects that depend on it.
And I would assume that older projects would most likely already have their dependencies version locked anyways.
Python 2 is end of life and no longer receiving any security updates, you supporting Python 2 will just motivate others to not move on from insecure unmaintained dependencies.
You'll also be splitting up manpower by not just encouraging use of yt-dlp, which will affect everyone, not just those who insist on not realizing the past is the past.
You'll also be splitting up manpower by not just encouraging use of yt-dlp, which will affect everyone, not just those who insist on not realizing the past is the past.
To be fair, yt-dlp usually implements all of youtube-dl's commits pretty quickly (unless they conflict with yt-dlp), so youtube-dl continuing to be maintained won't negatively affect yt-dlp that much. Also, #30568 (comment) said that youtube-dl's readme will be updated to mention yt-dlp
Just your standard Internet hound.
Just to confirm, Python 2 (or 2 and < 3.6) compatibility wasn't originally a goal of the project since Python 3 appeared only after the project was created, but that level of compatibility is a goal now, since yt-dlp exists for more recent Python versions. And anyone who can practically do so should run a supported Python version, on which yt-dl should run equally well.
The project Readme should definitely be updated, in due course, as boehs suggests.
May I suggest going one step further and informing the user about yt-dlp every time they run youtube-dl --update, if youtube-dl detects that it's running on python 3.6 or above. The user would have to also be informed about the slight differences between youtube-dl and yt-dlp, and that if they update they need to move their config file. Obviously this would be controversial and have downsides, one of which is that it may result in yt-dlp users accidentally reporting issues on the youtube-dl repository.
EDIT: Sorry boehs for the ping, it was an accident
I'd suggest you to unpin (or move to the lowest) #27013 because its title is a bit confusing.
Anyway, I'd appreciate youtube-dl now have a new maintainer.
@gamer191 wrote:
May I suggest going one step further and informing the user about yt-dlp every time they run youtube-dl --update,...
You can suggest it, but I think just updating the documentation will be quite enough. Feel free to try your luck with a PR, though, but I don't fancy your chances.
@Lesmiscore wrote:
I'd suggest you to unpin (or move to the lowest) #27013 because its title is a bit confusing.
Good point, it's not exactly news now, and I hope it won't be again.
Stubbornly supporting products that are way past their due date is absurd. Stop poking at dead bodies and embrace change rather than avoid it at all cost.
Do what the CPython team did: grow some balls, deprecate and move on. People will be angry, it always happens. But enough people are angry now with this project supporting a Python release that is 12 years old.
It's not like deprecated software suddendly stops working. It just isn't maintained anymore: if anyone still needs Python 2.7 support it's either their fault or their problem to deal with and certainly not a good reason to stifle the projects' growth, creating confusion and splitting manpower across 2 projects doing basically the same thing
You can suggest it, but I think just updating the documentation will be quite enough. Feel free to try your luck with a PR, though, but I don't fancy your chances.
Nah, I don't have enough coding skills to do that. If anyone with more skills likes my idea though they're welcome to PR it, but it only received 4 "likes", so I agree that it probably won't be merged in
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
See https://github.com/ytdl-org for details of the yt-dl organisation and its current members.
"This organization has no public members. You must be a member to see who’s a part of this organization."
Not enlightening.
Indeed. So I don't think I'm giving anything away by listing the 6 members as myself, the previous two active maintainers, two of the active maintainers before them, and the project creator.
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
I was about to say that earlier.
I personally couldn't care less if you want to use Python 2.6, PHP 4.1 or Perl 5.0. I care whether the project is in the hands of people who believe in its original mission.
@dirkf Pretty sure a lot of people will be watching for some, a-hem, creatively named "experience-improving telemetry" PRs, if you catch my drift.
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
I was about to say that earlier.
I personally couldn't care less if you want to use Python 2.6, PHP 4.1 or Perl 5.0. I care whether the project is in the hands of people who believe in its original mission.
@dirkf Pretty sure a lot of people will be watching for some, a-hem, creatively named "experience-improving telemetry" PRs, if you catch my drift.
What does telemetry have to do with any of this? People here are talking about supporting an EOL platform and you want to randomly involve telemetry with it? wtf.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads. Typical antagonizing behavior from fiery FOSS zealots with too much time on their hands.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads.
I remember the creator has mentioned some past maintainers in their blog, so the organization member should be something like:
So I don't think I'm giving anything away by listing the 6 members as myself (https://github.com//dirkf), the previous two active maintainers (https://github.com//dstftw and https://github.com//remitamine), two of the active maintainers before them (https://github.com//phihag and https://github.com//FiloSottile), and the project creator (https://github.com//rg3).
5/6 Good work, though more slashes than necessary.
Writing here my hope (request?) here since it's not worth to make an issue just for it I think:
I'd like you to make a document about how EXE for youtube-dl was (and will be) built.
I know this repo has wine-py2exe.sh script and I tried it, but I can't make it work since no one left document except the script.
Thanks
edit: #30644
See af9e725#commitcomment-65689220.
Initially it'll have to be done as before (if that can be made to work) but I like the idea of putting the whole process on GH, which would also be some sort of self-documentation.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads. Typical antagonizing behavior from fiery FOSS zealots with too much time on their hands.
I was gonna say, there sure are a lot of people who are complaining about Python 2.6 compatability without ever having contributed to the codebase themselves!
[...] without ever having contributed to the codebase themselves!
As equally invalid reason as "latest" is an invalid version.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads. Typical antagonizing behavior from fiery FOSS zealots with too much time on their hands.
I was gonna say, there sure are a lot of people who are complaining about Python 2.6 compatability without ever having contributed to the codebase themselves!
I have had enough issues with integrating youtube-dl in my projects, I can't imagine how painful it would be to try contributing to it if Python 2.6 compatibility is one of the key goals...
Have you tried PRs? Anyway all this discussion about compatibility (including my own comment) should go into its own issue. Maybe GitHub has an announcement mechanism to use instead of just the issue tracker.
I wondered, but followed the existing practice. Anyhow, this issue is a good honeypot for such discussions.
Maybe GitHub has an announcement mechanism to use instead of just the issue tracker.
There is no announcement mechanism. Some repos post announcements in readme or release notes, but it's pretty much standard practice to use pinned issue for them. Github has "discussions", but pinned issues have much more discoverability than (pinned) discussions from my experience
It’s really just very very bad to have both projects, as it will cause resources (developer time, bug reports, time to port features from on to the other) dispersed on either of them.
Worse, chances are (unfortunately) good that not simply one of them will sooner or later die (like it was effectively the case with LibreOffice vs. OpenOffice).
youtube-dl/yt-dlp is by nature software that's quite volatile and doesn't need to run e.g. on servers that shouldn't change a lot for years... so wherever it's used, one likely has current Python and 3rd party users could adapt to yt-dlp (or have already done so).
So... wouldn't it be much better to simply join yt-dlp?
Or merge yt-dlp into this project. Just because the name youtube-dl is more catchy and well-known.
For the record I don't think python 2 support is necessary. I imagine youtube-dl is running mostly on servers and home computers with ample python 3 support. For the embedded machines powerful enough to run python (and not just C and assembly), well they should be able to compile or have python3 binaries.
Your imagination is limited, but fortunately unnecessary as actual examples where Python 2 support is required or useful were provided, including at least one platform that won't change for decades, if ever.
Compared to a word processor, yt-dl has to operate in a rapidly changing, not to say adversarial, environment where a frozen version would quickly become useless. Whereas word processor functionality has been static or degraded since Word 2000.
Your imagination is limited, but fortunately unnecessary as actual examples where Python 2 support is required or useful were provided, including at least one platform that won't change for decades, if ever.
Compared to a word processor, yt-dl has to operate in a rapidly changing, not to say adversarial, environment where a frozen version would quickly become useless. Whereas word processor functionality has been static or degraded since Word 2000.
You know they came up with a word for that: it's called deprecation. Keep the Python 2 compatible version around, but focus development efforts and resources towards a Python3-only version. I don't see why the project should be weighed down by some dead-end platform
Except that both projects are being developed together, that's the plan. Nothing should go to waste.
Except that both projects are being developed together, that's the plan. Nothing should go to waste.
Except that splitting the manpower between two projects is less efficient. Duh
So you propose youtube-dl as more compatible and yt-dlp as the development project? That is a possibility.
So you propose youtube-dl as more compatible and yt-dlp as the development project? That is a possibility.
The proposal would be to deprecate the current youtube-dl and move all future development efforts to yt-dlp
I haven't kept up to date on how much development effort each project gets.
@dirkf If you think that Python 2 support is worth it just because of how many people need it, then why not make a github poll asking if people actually need it? Would be a good way to prove you're not just speaking out of self interest.
@dirkf If you think that Python 2 support is worth it just because of how many people need it, then why not make a github poll asking if people actually need it? Would be a good way to prove you're not just speaking out of self interest.
It's not about self interest but a common problem of compatibility versus using newer languages and libraries. Also a poll should be limited to recent top contributors or and end user survey.
I'm definitely speaking out of self-interest, but not only that, as previously stated.
My position is settled for moment in line with #30568 (comment) and
#30568 (comment).
I'm definitely speaking out of self-interest, but not only that, as previously stated.
My position is settled for moment in line with #30568 (comment) and #30568 (comment).
What's wrong with instead of the decision being only up to you but instead leave it up for others to have a vote in the matter? A survey for contributors and end users sounds reasonable.
Feel free to run your project on those lines, or to suggest that at yt-dlp. There are more important practical issues to be addressed here.
Doing software development driven by public "polls" sounds like a really bad idea to me.
That comes with the territory when there's not a reliable set of core developers.
I'll not give my point of view about Python 2 support, but if some data is needed to help making a decision about when to stop in the future, I have actual data from PyPI downloads that I update monthly:
=> https://github.com/JulienPalard/python-versions
The graph don't show Python 2.6 (it's stuffed in "other") but running the script shows a table with many details, in it Python 2.6 is at 0.000% downloads since 2021-06, as seen by PyPI.
Interesting stats, although the "problem" installations aren't going to show on PyPi, and may just be running this one Python program, updated by the distro package manager.
yt-dlp's requirements are met by 80% or so of PyPi downloads.
As far as 2.6 is concerned it's possible that some incompatibilities have crept in without anyone complaining, since the automated tests don't test 2.6.
My research highlights these as being the differences introduced in 2.7, plus a few more minor items:
- mutable set literal syntax
- dictionary and set comprehensions
- multiple context managers in a single with statement.
- OrderedDict
,thousands separator format specifiermemoryviewargparselogging.config.dictConfigdictviewkeys(),viewvalues(),viewitems()(dead-end synonyms for Py3 keys(), values(), items())- automatic numbering of
str.format()replacement fields ('abc{}def{}'vs'abc{0}def{1}') bit_lengthmethod ofintandlong@classmethodand@staticmethodwrapped methods expose the wrapped function as__func__.
A simple check confirms that there are no instances of OrderedDict or dict.viewxxxs(), but surely there must be a dictionary comprehension somewhere in yt-dl?
There are dict comprehensions. They currently use the pattern dict((k, v) for ...). But imho, it is not worth just dropping 2.6. The maintenance cost b/w 2.6-2.7 is very small.
Edit: unless we want to switch to optparse. But I doubt anyone wants to put in the effort to actually do that
Same reason why yt-dlp has no plans to drop 3.6 compat despite it being EOL - the benefits of 3.7 are minimal
Just wondering, does YouTube-DL have any plans to drop official support for avconv, like yt-dlp did? (Personally, I don’t use avconv)
name youtube-dl is more catchy and well-known
and thus maybe more exposed to DCMA action by Google/youtube ?
It sounds like there is some admission that this project will not be the standard bearer for YouTube downloading. I just hope that if Python2 and a different set of defaults is all that is justifying this projects existence that the docs are clear about that, and point to yt-dlp as the replacement.
Personally, I don't see the value in what is being done. I'll point to Mikeal's post on Request for how a project should end
The best thing for these new modules is for
requestto slowly fade away, eventually becoming just another memory of that legacy stack. Taking the positionrequesthas now and leveraging it for a bigger share of the next generation of developers would be a disservice to those developers as it would drive them away from better modules that don’t have the burden ofrequest's history.
I think that's the real point here. This project will serve to confuse new developers, and the community is better if it fades away.
It sounds like there is some admission that this project will not be the standard bearer for YouTube downloading. I just hope that if Python2 and a different set of defaults is all that is justifying this projects existence that the docs are clear about that, and point to yt-dlp as the replacement.
Personally, I don't see the value there. I'll point to Mikeal's post on Request for how a project should end
The best thing for these new modules is for
requestto slowly fade away, eventually becoming just another memory of that legacy stack. Taking the positionrequesthas now and leveraging it for a bigger share of the next generation of developers would be a disservice to those developers as it would drive them away from better modules that don’t have the burden ofrequest's history.I think that's the real point here. This project will serve to confuse new developers, and the community is better if it fades away.
Very well said
Just wondering, does YouTube-DL have any plans to drop official support for avconv, like yt-dlp did?
In so far as any plans exist, removing code that handles avconv wouldn't be in them. Possibly some new feature might be conditional on a newer version of ffmpeg and not avconv.
dict comprehensions. They currently use the pattern
dict((k, v) for ...)
Whereas the newer non-2.6 version would be {(k, v) for ...}
So your plan is to turn youtube-dl into the OpenOffice of web video downloaders, great stuff. As if the FOSS community needed yet another big slap in the face like that.
Other people above have already explained clearly enough why insisting on supporting EOL Python versions is a bad idea, so I'm not going to repeat them.
I'm definitely speaking out of self-interest, but not only that, as previously stated.
This project has grown well beyond the pet-project "if-you-don't-like-it-fork-it-or-don't-use-it" status. The community that grew around youtube-dl was never here for the project's support of Python 2.6. The implicit "social contract" of this project was never one of favoring extreme backwards compatibility over everything else - including to the detriment of ease of development, developer experience and contributing to fragmentation across two projects.
Whether you like it or not, if your "self-interest" is to move in the direction of supporting legacy EOL stuff, then by all means, fork youtube-dl into something called "youtube-dl-oldpy" or something, and continue your work there. It is clear that using this repo for that niche purpose is not in the community's best interest. The right thing to do for the community is to continue the development of the non-legacy project under the most widely known "brand", and not create additional confusion. More precisely, this is what I would do:
- Move yt-dlp development into youtube-dl.
- Archive the yt-dlp repo and point towards youtube-dl.
- Mention the "oldpy" fork in the readme.
or, alternatively:
- Archive this repo and point to yt-dlp
- Mention the "oldpy" fork in the readme.
Your imagination is limited, but fortunately unnecessary as actual examples where Python 2 support is required or useful were provided, including at least one platform that won't change for decades, if ever.
Care to elaborate on that? What are those use cases? Should the needs of those who have those use cases be imposed against the wishes and best-interests of the remaining 99% of the community?
As others have said before, if there's people stuck with EOL stuff, that's their problem. If they don't want/are too lazy to do the right thing and upgrade, they can either hope for some generous soul such as you to maintain a separate fork that maintains compatibility, or actually pay someone to do it (like a support contract).
You don't have to feel bad for changing your stance on this subject. I'm sure you've heard of this famous example. Kovid is a great developer and an awesome person for his many contributions to FOSS, but everyone makes mistakes and says dumb things every once in a while. The community is there to call that out when it happens, and you'll still have its support after the drama blows over - unless you stubbornly and irrationally insist on the wrong decision for the project. Nobody wants Apple-like "courage" in FOSS.
Archiving the project would amount to deleting it since it would not be updated in line with changes in the web environment.
Generally, people who want to advance the project should submit their PRs that follow the project's coding conventions for consideration either here or at yt-dlp. The project can sort out any Py2.x issues, where possible.
Archiving the project would amount to deleting it since it would not be updated in line with changes in the web environment.
Generally, people who want to advance the project should submit their PRs that follow the project's coding conventions for consideration either here or at yt-dlp. The project can sort out any Py2.x issues, where possible.
You should've told everyone to STFU before trying to defend your position on supporting a dead-end legacy language. At least it would've been clear to everyone reading here that the sole reason for this is "wah wah the project is mine and I take the decisions and if you don't like it just fork it and stfu!1!!11!!"
Also, from the linked famous example:
Kovid has stated numerous times that any patches which work towards
python3 compatibility without hurting python2 functionality or
performance would be happily accepted. Oddly enough, no one has ever
taken him up on that, though a number of people have insisted it is
very important that he himself do that work.
Hahaha.
Let me state categorically that no PRs that are incompatible with Python 3, especially a supported version, will be acceptable.
I never said archiving this repository would be the only required thing to do, or indeed the only option.
Also, from the linked famous example:
LOL, is that cherry-picked quote the hill you want to die on? You do know the end to that story, don't you? Calibre dropped support for Python 2.
But a perhaps better example of responsible maintainership was also linked above, in case you missed it: request/request#3142.
You're not addressing the substance of the arguments that people are putting forward.
I think this is everything everyone needs to know about this new "management".
Just to confirm, Python 2 (or 2 and < 3.6) compatibility wasn't originally a goal of the project since Python 3 appeared only after the project was created, but that level of compatibility is a goal now,
Says who? Why is it a goal now? When and How was it decided? You just decided this on your own without taking the needs and opinions of the community into account? That is not how you deal with a project of this size or reach.
Feel free to make decisions that way on your own separate niche fork, where you don't have to answer to anyone about what you decide to do with it (you could make it output ASCII nyan cats to stdout every 5 seconds if you want, no questions asked), but this is not the right way to do things here.
Half off-topic, but similar reason keeps lot of Linux distros bloated too as there is lot of ancient and different languages/versions/runtimes included.
Python 2.x:
- Move yt-dlp development into youtube-dl.
- Archive the yt-dlp repo and point towards youtube-dl.
Just to be clear, this is not hapenning
You should've told everyone to STFU
I would still rather see the PRs from the committed FOSS community: where are they?
It's bad enough that one guy in Nebraska supports the whole Internet with no support from businesses that rely on him (examples passim), but the committed FOSS community wasn't much help either.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
You should've told everyone to STFU
I would still rather see the PRs from the committed FOSS community: where are they?
It's bad enough that one guy in Nebraska supports the whole Internet with no support from businesses that rely on him (examples passim), but the committed FOSS community wasn't much help either.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
As much as I understand the potential need to support it. I'm not sure if that's a solid foundation to hold your stance on. We're currently talking about quite the niche and we're now also talking about multiple pieces of software that already have reached EOL (Officially) which should have little ground to actively support.
If the project desperately needs to support these versions, shouldn't that be a fork of it's own? Instead splitting up upstream into multiple projects that shouldn't that be done downstream instead? I don't understand the logic to do it the other way around, especially since there's realistically speaking more users of this project that actually already have moved on to supported versions of python and supported OS's too.
Are people coming here from this mistitled post or one of its many clones? 🤔
It's bad enough that one guy in Nebraska supports the whole Internet with no support from businesses that rely on him (examples passim), but the committed FOSS community wasn't much help either.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
You are have only been "that guy" as maintainer for less than a week, far less than what Sergey M has put in.
(Also, for the record, linking Iggy Azalea should be automatic grounds for being removed as maintainer.)
And you do know that ESM is when your business specifically pays Canonical to continue life support because your boss or the business side bean-counters really doesn't want to upgrade? It's not for normal people.
On slashdot? Maybe I should just retire now ...
You are have only been "that guy" as maintainer for less than a week, far less than what Sergey M has put in.
Not claiming otherwise, but no-one got on Sergey's case about the project coding conventions, which have not changed.
(Also, for the record, linking Iggy Azalea should be automatic grounds for being removed as maintainer.)
Could be fair comment, or was it just an ironic link?
And you do know that ESM is when your business specifically pays Canonical ...
Or, for limited personal use, free, for when you have your Emacs set up just how you like it and don't want to spend time redoing it.
You should've told everyone to STFU
I would still rather see the PRs from the committed FOSS community: where are they?
It's bad enough that one guy in Nebraska supports the whole Internet with no support from businesses that rely on him (examples passim), but the committed FOSS community wasn't much help either.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
Ubuntu 16.04 reached EOL on April 30th 2021 unless you explicitly buy an annual Extended Security Maintenance license. Someone so desperately going trough that length to keep Python 2.7 surely knows how to use a deprecated fork of a tool. My argument was just to deprecate the current youtube-dl, not to delete it entirely.
It seems to me you're not even trying to address our claims and just keep coming back at us with "well, where are the pull requests????". If that's your problem, I'll gladly make a PR that drops Python 2 support entirely :)
I'll probably get mocked for this, but I have an old system that is running an old version of Windows. NONE of the forks work for me. As in they literally will NOT run on my system. YouTube-DL is literally the only version that I can run. I'd love to be using a more up to date program with less issues, but I can't.
I don't have the money to buy a new system and even if I did, I really don't want Win10/11 with their forced updates. I know, just move to Linux! I know absolutely NOTHING about using Linux. I don't know how to install software under it, how to configure it, how to use it, etc.
So for now, I'm stuck with what I have. It's either use YouTube-DL or nothing.
@Rekrullurker (seems way off topic) when you say "does not work" did you open an issue on yt-dlp you can link where you tried to get support or ask a question on SuperUser with more information? I'd love to know your error. Python3 is supported on all machines Windows 8 and newer, and yt-dlp doesn't require anything more than that.
Also there are unofficial python 3 32 bit binaries that should work.
I'll probably get mocked for this, but I have an old system that is running an old version of Windows. NONE of the forks work for me. As in they literally will NOT run on my system. YouTube-DL is literally the only version that I can run. I'd love to be using a more up to date program with less issues, but I can't.
I don't have the money to buy a new system and even if I did, I really don't want Win10/11 with their forced updates. I know, just move to Linux! I know absolutely NOTHING about using Linux. I don't know how to install software under it, how to configure it, how to use it, etc.
That's your problem, and a bunch of learned helplessness.
What do you think is more reasonable?
a) Just upgrade to Windows 10/11 (as much hate as Windows deserves, the "the forced updates" meme is waaaaay overblown nowadays). No money is not an excuse, it's actually a free upgrade (but I would recommend Linux anyway). If you do decide to go with Windows 10/11 but your system is really so old it does not support it (somewhat doubtful, the oldest CPUs Windows 10 support are from 2004 (!)), then consider Linux, or searching for better deals in the used market. Decent machines for basic/office work that actually support Windows 10 can be had for about $50 or less in used condition.
b) Learn how to install and use Linux. It's really a very trivial process nowadays, and you can always use Windows in a virtual machine or Wine if you really need Windows-specific stuff for workflows for which you could not find replacements for on Linux or to which you can't adapt to despite your best efforts to do so. Bonus: you could get a Raspberry Pi for ~$45 ($35 + ~$10 microsd card), that way you get to learn Linux and a new system that's even suitable for basic/office use.
c) Beg online that a FOSS project handicaps itself just so that you don't have to put any effort into maintaining your own setup.
Please don't validate the new maintainer's irresponsible and misguided "noble cause" of maintaining unreasonable, detrimental levels of backwards compatibility. You are not some "poor little user" whose life will be in shambles should the project drop support for EOL stuff. As I've shown above, you have multiple options - real, actionable courses of action that will also benefit you in other ways other than the specific issue of being able to continue to run youtube-dl or its forks.
It's bad enough that one guy in Nebraska supports the whole Internet ...
This is a poor comparison. That comic is about critical network infrastructure way down the stack, youtube-dl is a user-facing program with high code-churn due to the nature you YouTube and other sites themselves.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
Users of 16.04 ESM are not your users. They are are enterprises with paid support contracts to Canonical, because their resident bean counters determined it would be cheaper, at least in the short-mid term, to keep paying Canonical for critical unofficial backports for software such as Python instead of following proper practices and keeping their tech stacks up to date.
So, is anyone paying you for your efforts? No? Then is there widespread demand and expectation from the community that this is the best course for the project? Also no? Hmmm...
I'll probably get mocked for this, but I have an old system that is running an old version of Windows. NONE of the forks work for me. As in they literally will NOT run on my system. YouTube-DL is literally the only version that I can run. I'd love to be using a more up to date program with less issues, but I can't.
I don't have the money to buy a new system and even if I did, I really don't want Win10/11 with their forced updates. I know, just move to Linux! I know absolutely NOTHING about using Linux. I don't know how to install software under it, how to configure it, how to use it, etc.
That's your problem, and a bunch of learned helplessness.
What do you think is more reasonable?
a) Just upgrade to Windows 10/11 (as much hate as Windows deserves, the "the forced updates" meme is waaaaay overblown nowadays). No money is not an excuse, it's actually a free upgrade (but I would recommend Linux anyway). If you do decide to go with Windows 10/11 but your system is really so old it does not support it (somewhat doubtful, the oldest CPUs Windows 10 support are from 2004 (!)), then consider Linux, or searching for better deals in the used market. Decent machines for basic/office work that actually support Windows 10 can be had for about $50 or less in used condition.
b) Learn how to install and use Linux. It's really a very trivial process nowadays, and you can always use Windows in a virtual machine or Wine if you really need Windows-specific stuff for workflows for which you could not find replacements for on Linux or to which you can't adapt to despite your best efforts to do so. Bonus: you could get a Raspberry Pi for ~$45 ($35 + ~$10 microsd card), that way you get to learn Linux and a new system that's even suitable for basic/office use.
c) Beg online that a FOSS project handicaps itself just so that you don't have to put any effort into maintaining your own setup.
Please don't validate the new maintainer's irresponsible and misguided "noble cause" of maintaining unreasonable, detrimental levels of backwards compatibility. You are not some "poor little user" whose life will be in shambles should the project drop support for EOL stuff. As I've shown above, you have multiple options - real, actionable courses of action that will also benefit you in other ways other than the specific issue of being able to continue to run youtube-dl or its forks.
It's bad enough that one guy in Nebraska supports the whole Internet ...
This is a poor comparison. That comic is about critical network infrastructure way down the stack, youtube-dl is a user-facing program with high code-churn due to the nature you YouTube and other sites themselves.
Also, regardless of bloat, the default Python in Ubuntu 16.04, ESM to 2026, is 2.7.12.1. Python 3 is 3.5.2. Installing a "supported" Python, eg for yt-dlp, requires a PPA.
Users of 16.04 ESM are not your users. They are are enterprises with paid support contracts to Canonical, because their resident bean counters determined it would be cheaper, at least in the short-mid term, to keep paying Canonical for critical unofficial backports for software such as Python instead of following proper practices and keeping their tech stacks up to date.
So, is anyone paying you for your efforts? No? Then is there widespread demand and expectation from the community that this is the best course for the project? Also no? Hmmm...
Very well said.
I'll probably get mocked for this, but I have an old system that is running an old version of Windows. NONE of the forks work for me. As in they literally will NOT run on my system. YouTube-DL is literally the only version that I can run. I'd love to be using a more up to date program with less issues, but I can't.
I don't have the money to buy a new system and even if I did, I really don't want Win10/11 with their forced updates. I know, just move to Linux! I know absolutely NOTHING about using Linux. I don't know how to install software under it, how to configure it, how to use it, etc.
So for now, I'm stuck with what I have. It's either use YouTube-DL or nothing.
So our question is, is your usecase more important to the project than developers using non-obsolete versions of python? Depends on the scope and mission of the project. @dirkf would say so, others would not. Maybe we can drag @dstftw back from the dead to give an answer with some amount of authority.
@EvanCarroll - No, I didn't open an issue because I'm very familiar with what happens when a program needs a newer version of Windows than I have.
@Others - I'm sorry. I wasn't aware that printing text to a console window, making a connection on the net and downloading data was such a complex task that it needs state of the art software. I mean, sure computers have been doing that since the days of MS-DOS, but obviously downloading from video sites is a much more demanding task that can only be accomplished using an up to date programming language.
Forgive me for wanting this horribly outdated project to continue as it has been, when obviously, it is vitally necessary that only the newest version of Python be used! And obviously, the maintainers of this particular project should be taken out back and horsewhipped for daring to use an outdated version!
You're missing the point. It's not that it can't be done with Python 2. Hell, you could even use COBOL, or whatever vintage tech stack you prefer. But this is not just some toy HTTP downloader that you might implement over an afternoon/weekend in your language of choice and then forget about. This is a very widely-used project with very high code-churn - it must keep up with the ever-changing mechanisms YouTube and other service employ to serve video. It is essential that the project remains easy to contribute to. This means, among other things, shedding legacy cruft as it is EOL'd. Otherwise, you're creating friction for new contributors, and you might run out of contributors to deal with the high rate of change required in a timely fashion, and the project may eventually die because of this.
Remember, due to the changes YouTube and other services constantly make, programs such as youtube-dl may cease to work overnight. Lots of end-users now depend on youtube-dl working reasonably around the clock, including archivist activists that save important pieces of evidence before they are scrubbed from online platforms. If it is implemented in an obsolete language, there will be a smaller pool of potential contributors who will bother to try to post a fix in a reasonable time.
But, anyway, you are misrepresenting all the things that youtube-dl actually does:
computers have been doing that since the days of MS-DOS
This implies that what youtube-dl does could be achieved with both:
- MS-DOS-era language/stack (true, any turing-complete language will do obviously, but for the sake of the project's health and longevity you don't actually want to use something obsolete for the reasons stated above).
- MS-DOS-era hardware (false)
youtube-dl not only downloads video chunks, it also decodes youtube's rolling cipher (and other similar shenanigans), remuxes audio/video/etc, wrangles JSON, and even optionally re-encodes media streams (with the help of ffmpeg). So again, no, this not just "making a connection, printing text to the console and downloading data". Good luck running that on your 486. What you describe is more akin to the requirements and functionality of a basic IRC client. Not to mention that you'd quickly fill up period-accurate hard-drives even with "just" 1080p video.
This landscape is constantly evolving, and you must either keep up or find some other solution for yourself.
In fact, I doubt you could even play back the videos you download with average hardware older than about 2006-2007 - modern video codecs are quite complex. I happen to own an old ~2006-7 laptop with a C2D processor/4 GiB RAM for potential emergencies (it also has an SSD, which, while severely bottlenecked by the rest of the system, it does its job and makes the laptop very usable, because it greatly speeds up what is most important to speed up: random I/O). It can just barely manage 720p45 with the CPU at full beans last time I tried. But hey, turns out even such an old machine is x86-64. That's right, yes, that does mean I have a modern mainstream Linux distro installed on it, and yes, that means I can - gasp! - run non-EOL Python versions on it!
TL;DR - it's not a matter of whether maintaining youtube-dl with backwards compatibility for legacy crap XYZ can or cannot be done (from a purely theoretical technical standpoint, of course it can always be done), it's about opting for the optimal way to do maintain it given the unique characteristics, constraints, and context of the project, and its community.
@EvanCarroll - No, I didn't open an issue because I'm very familiar with what happens when a program needs a newer version of Windows than I have.
@Others - I'm sorry. I wasn't aware that printing text to a console window, making a connection on the net and downloading data was such a complex task that it needs state of the art software. I mean, sure computers have been doing that since the days of MS-DOS, but obviously downloading from video sites is a much more demanding task that can only be accomplished using an up to date programming language.
Forgive me for wanting this horribly outdated project to continue as it has been, when obviously, it is vitally necessary that only the newest version of Python be used! And obviously, the maintainers of this particular project should be taken out back and horsewhipped for daring to use an outdated version!
As @FranciscoPombal already said, just because it can be done in legacy languages doesn't mean it should. Maintainability is the key to the survival of projects like this, where the rate of change is extremely fast. Just because a shoe can somewhat hammer a nail doesn't mean one should use it in place of a hammer. Funny how you used sarcasm and ended up just making a fool of yourself
Pointless innovation, as illustrated by Chrome, is a damaging strategy akin to continuous revolution in communist China and Cambodia.
Python 3 is certainly not pointless, but even Python 3.11 is a supported target for yt-dl. Code that runs only in 3.11 would be bad code. Good code should be easy to support in yt-dl.
When, say, Francisco submits a PR addressing one of the project's 4000+ other outstanding issues, we'll see whether the PR is worthwhile and how it can be incorporated in the project's codebase.
Opining on strategy is a lot easier than making reliable solid code, which accounts for the problems that I mentioned previously. The Internet protocols were created from rough consensus and working code, which proved to be a better development model than a standards committee (and I spent plenty of time in those). To change the project's coding conventions (or external dependencies) in a way that reduced the wide variety of platforms in which yt-dl can run, there would need to be actual examples of worthwhile features that can't straightforwardly be supported.
As to platforms, while it somewhat postdates the MS-DOS era, a MIPS-32 400MHz dual-core CPU with a hardware H.264 decoder is quite capable of running yt-dl under Py 2.7 as well as ffmpeg 4 and playing the resulting videos up to 1080p. A device like this has a potential further in-service life of at least 10 years. Maybe a future web ecosystem where we have, say, to send an iris print to President Xi, or execute 50MB of WASM, before making any web request will render the current yt-dl architecture unviable. Let's see.
Pointless innovation, as illustrated by Chrome, is a damaging strategy akin to continuous revolution in communist China and Cambodia.
Python 3 is certainly not pointless, but even Python 3.11 is a supported target for yt-dl. Code that runs only in 3.11 would be bad code. Good code should be easy to support in yt-dl.
When, say, Francisco submits a PR addressing one of the project's 4000+ other outstanding issues, we'll see whether the PR is worthwhile and how it can be incorporated in the project's codebase.
Opining on strategy is a lot easier than making reliable solid code, which accounts for the problems that I mentioned previously. The Internet protocols were created from rough consensus and working code, which proved to be a better development model than a standards committee (and I spent plenty of time in those). To change the project's coding conventions (or external dependencies) in a way that reduced the wide variety of platforms in which yt-dl can run, there would need to be actual examples of worthwhile features that can't straightforwardly be supported.
As to platforms, while it somewhat postdates the MS-DOS era, a MIPS-32 400MHz dual-core CPU with a hardware H.264 decoder is quite capable of running yt-dl under Py 2.7 as well as ffmpeg 4 and playing the resulting videos up to 1080p. A device like this has a potential further in-service life of at least 10 years. Maybe a future web ecosystem where we have, say, to send an iris print to President Xi, or execute 50MB of WASM, before making any web request will render the current yt-dl architecture unviable. Let's see.
The fact that you were able to make this argument political shows just how much of a fool you are. If you have nothing intelligent to say, just don't say anything, surely better than the dumpster of a fire this issue has become because of your answers that make zero sense whatsoever and seem to outright skip all of the valid points that we've brought up. Enjoy dictating over what's good or bad for the future of the project, just don't pretend it's a community effort anymore and don't make it look like this is the best course of action for everyone, because it is most clearly not.
In case it wasn't obvious, I'm not going to allow personal abuse in any discussions in the project, even if standards may have dropped during the interregnum. People can have different views without being stupid or mad. Let actions and code speak for themselves.
In case it wasn't obvious, I'm not going to allow personal abuse in any discussions in the project, even if standards may have dropped during the interregnum. People can have different views without being stupid or mad. Let actions and code speak for themselves.
So if the answer doesn't suit your narrative you just shut it down. How convenient
Obviously not, as illustrated above.
In case it wasn't obvious, I'm not going to allow personal abuse in any discussions in the project, even if standards may have dropped during the interregnum. People can have different views without being stupid or mad. Let actions and code speak for themselves.
I agree with you, but political polemics and exaggerations aren't helping your case.
Pointless innovation, as illustrated by Chrome, is a damaging strategy akin to continuous revolution in communist China and Cambodia. Python 3 is certainly not pointless, but even Python 3.11 is a supported target for yt-dl. Code that runs only in 3.11 would be bad code. Good code should be easy to support in yt-dl.
[...]
As to platforms, while it somewhat postdates the MS-DOS era, a MIPS-32 400MHz dual-core CPU with a hardware H.264 decoder is quite capable of running yt-dl under Py 2.7 as well as ffmpeg 4 and playing the resulting videos up to 1080p. A device like this has a potential further in-service life of at least 10 years. Maybe a future web ecosystem where we have, say, to send an iris print to President Xi, or execute 50MB of WASM, before making any web request will render the current yt-dl architecture unviable. Let's see.
Opinions on Maoism, Python 3.11, MIPS-32, and web assembly all in the same response. Kudos. Both your response and your maintainership have the same admirable quality of being succinct and well thought out.
best of luck moving forward continuing to maintain youtube-dl
For what it's worth, I'm glad to see that @dirkf and @pukkandan are able to work together to maintain a constructive relationship and share code between the projects. If either one of them would've had a big ego or been absolutist to the point of some people above, both projects would have ended up suffering for it.
Time will tell whether maintaining both in parallel is feasible or if one eventually supplants the other. These things do not have to be settled in one week.
Pointless innovation, as illustrated by Chrome, is a damaging strategy akin to continuous revolution in communist China and Cambodia.
I actually respect and appreciate your militant positions, I know Free Software is inherently political. FYI for others - a very effective strategy that political opponents of Free Software have been running for nearly a decade now is to poison the well with pointless identity politics. They're toxic and pointless, and drain everyone's energy to engage in the actually important and productive political side of Free Software - hence the averse reaction to "turning a discussion political". If you want to separate Free Software from the fight against against dictatorial regimes and techo-corporate "you will rent everything, own nothing, and be happy" dystopia, you're missing a huge part of its point, and you should consider that you may have already been successfully conditioned by your enemies into becoming a pawn for their side. Recommended reading.
Side note: yep, I do wish youtube-dl were licensed differently ([A]GLPv3), but oh well.
Python 3 is certainly not pointless, but even Python 3.11 is a supported target for yt-dl. Code that runs only in 3.11 would be bad code. Good code should be easy to support in yt-dl.
This misrepresents my point. I never said new code written now should only run on 3.11. I am advocating for raising the minimum supported version as time goes on. For instance, it would be acceptable to submit code that only runs on >= 3.7, since that is the last non-EOL version currently.
When, say, Francisco submits a PR addressing one of the project's 4000+ other outstanding issues, we'll see whether the PR is worthwhile and how it can be incorporated in the project's codebase.
My point is precisely that you would have an easier time finding contributors to address the project's 4000+ other outstanding issues if you don't sacrifice excessive amounts of developer ergonomics on the altar of excessive backwards compatibility on what is the de facto "main version" of youtube-dl. As I've said before, I would have no issue with you doing this for a separate niche fork with the express goal of extreme backwards compatibility.
To change the project's coding conventions (or external dependencies) in a way that reduced the wide variety of platforms in which yt-dl can run, there would need to be actual examples of worthwhile features that can't straightforwardly be supported.
You are assuming there was already a convention in place supporting extreme backwards compatibility. In reality, youtube-dl has historically supported python 2.7 not because it was somehow decided that was important at the time, but simply because that was "the done thing" when youtube-dl was created. Then, 2.7 compatibility simply stuck around because it apparently didn't bother the maintainers, despite how much it inconvenienced contributors and potential contributors.
Though implicit, IMO the main goal of youtube-dl has always been to keep up with the changes in the various websites it supports as quickly as possible. As I've argued above, optimizing for this implies optimizing for the number of contributors and developer ergonomics (while not sacrificing ease of use too much by, say, requiring 3.11 exclusively or something). Maintaining extreme backwards compatibility with EOL versions runs counter to this.
Now you are trying to impose an explicit new direction for the project - that of extreme backwards compatibility, which may compromise youtube-dl's ability to keep up as fast as it otherwise could.
Again, you might argue that's the role yt-dlp fulfills. But again, as I've argued above, naming is important, and many people don't know about yt-dlp, just youtube-dl. That's why I've been saying that youtube-dl itself should have the goals you now ascribe to yt-dlp, and that it would be preferable to continue the effort of maintaining extreme backwards compatibility on a separate fork, not the main youtube-dl repo.
As to platforms, while it somewhat postdates the MS-DOS era, a MIPS-32 400MHz dual-core CPU with a hardware H.264 decoder is quite capable of running yt-dl under Py 2.7 as well as ffmpeg 4 and playing the resulting videos up to 1080p. A device like this has a potential further in-service life of at least 10 years.
Has any real user even mentioned that use case? It sounds like you're maintaining industrial hardware under some support contract. Or some kind of "TV set-top" box use case.
Maybe a future web ecosystem where we have, say, to send an iris print to President Xi, or execute 50MB of WASM, before making any web request will render the current yt-dl architecture unviable. Let's see.
Unfortunately we might be closer to something resembling such a situation that what you may think. I cannot be convinced that the forced TPM* requirement for Windows 11 and the new Microsoft "security chips" inside new AMD CPUs are not efforts to prime the masses for such a future.
*TPM itself is not a bad thing, but the way they are intended to be used in the mass consumer market certainly is extremely user hostile - we all know the only accepted attestations will be the one signed by root certs controlled by a few corps.
[redacted verbatim quote of previous post, with apologies]
You are right about my reaction to trying to "make the discussion political". I'm just tired of the pointless debating that seems to be so popular these days (you mentioned identity politics, which is a hot topic it seems) because, as you rightly said, it distracts us from the real point. So whenever I see politics mentioned in an IT/CS discussion I just roll my eyes almost instinctively because I have been exposed all too often to cringy movements the likes of "Let's change the default branch name of git to main!!!!" or "The Santa hat in vscode is offensive because we're not all Christian!!!!"
... I never said new code written now should only run on 3.11. ...
Agreed. But it can also be observed that compatibility between Py 3 versions is only assured if a conservative (and I don't mean that politically!) coding style is used.
My point is precisely that you would have an easier time finding contributors to address the project's 4000+ other outstanding issues if you don't sacrifice excessive amounts of developer ergonomics on the altar of excessive backwards compatibility ...
You are assuming there was already a convention in place supporting extreme backwards compatibility. ...
There was a convention in place, as you relate. 'Extreme' and 'excessive' are your descriptions of it.
In fact, it has been demonstrated that innovations from yt-dlp can generally be adopted into yt-dl quite easily, unless the code has diverged so significantly that code reconciliation is the hurdle rather than Python versions. The project coding conventions allow contributions to be made that will run in Py 2.7 without the contributor having to understand compatibility issues. As always, it is good practice when adding to a program to read the existing code and use that style in one's additions, but if someone offers a contribution that only runs in Py 3, assistance can be provided.
It could be argued that previous hard-worked maintainers were prone to reject or ignore PRs without explaining why, or how they could be made acceptable, but (a) sometimes this decision was correct (see, eg, discussion in PR #30329) (b) I haven't seen any case where the problem was Py 2.7 compatibility (whereas I have seen the reverse).
Though implicit, IMO the main goal of youtube-dl has always been to keep up with the changes in the various websites it supports as quickly as possible. ...
Agreed.
Now you are trying to impose an explicit new direction for the project ...
No.
Again, you might argue that [keeping up with web churn] is the role yt-dlp fulfills. ...
If change proposals require extra external dependencies, yt-dlp is probably a better target. My perception is that there are many users who have enough trouble just opening a command-line prompt and want the program to "just work": so changes shouldn't make it more difficult to install the program or require non-default options for those users. Then there are users who have developed a more complicated workflow that they may see as the one true use case: we have to assess whether changes that suit one of those groups are worthwhile given possible unwanted side-effects or feature clash. And we can't forget the many projects that embed yt-dl and for which we have to maintain the signature and semantics of the program's APIs. Fortunately, as long as the extractor API remains stable, each project can address web churn to the benefit of both, and in fact there may be benefit in some element of competition.
... it would be preferable to continue the effort of maintaining extreme backwards compatibility on a separate fork, not the main youtube-dl repo.
You'll already have seen that the yt-dlp maintainer doesn't want to take over yt-dl. So your proposal would mean three projects instead of two: I don't think that would be an improvement.
Also, what @Zirro said.
...
Has any real user even mentioned that use case? It sounds like you're maintaining industrial hardware under some support contract. Or some kind of "TV set-top" box use case.
Exactly that. What better use for yt-dl than to supplant a poorly designed, dysfunctional or obsolete OEM "smart TV" app? And it runs in your Apple M1 too.
...
Unfortunately we might be closer to something resembling such a situation that what you may think. ...
What I think did inspire my choice of possible dystopic futures, exaggerated though I hope they will remain.
@dirkf Would you be open to a Readme-PR, which would tell people about yt-dlp? =)
See #30568 (comment). By all means have a go: your text may be better than what I was going to include in the next release.