Under new management #24950

Author

Owner

@Twangist commented on GitHub (Jan 29, 2022):

Supporting defunct versions of Python seems like a great way to handicap the project and a total waste of time.

@Twangist commented on GitHub (Jan 29, 2022): Supporting defunct versions of Python seems like a great way to handicap the project and a total waste of time.

deekerman commented

Author

Owner

@boehs commented on GitHub (Jan 29, 2022):

This repository should just become yt-dlp tbh

@boehs commented on GitHub (Jan 29, 2022): This repository should just become yt-dlp tbh

deekerman commented

Author

Owner

@VixieTSQ commented on GitHub (Jan 29, 2022):

this is ridiculous. Python 2 is dead

@VixieTSQ commented on GitHub (Jan 29, 2022): this is ridiculous. Python 2 is dead

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Jan 29, 2022):

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

@pukkandan commented on GitHub (Jan 29, 2022): > 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

deekerman commented

https://www.python.org/doc/sunset-python-2/

Author

Owner

@ligix commented on GitHub (Jan 29, 2022):

fyi python 2 reached EOL 2 years ago, before windows 7 did.

@ligix commented on GitHub (Jan 29, 2022): fyi python 2 reached EOL **2 years ago**, before windows 7 did. https://www.python.org/doc/sunset-python-2/

deekerman commented

Author

Owner

@boehs commented on GitHub (Jan 29, 2022):

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?

@boehs commented on GitHub (Jan 29, 2022): > > 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?

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 29, 2022):

@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.

@dirkf commented on GitHub (Jan 29, 2022): @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.

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Jan 29, 2022):

https://github.com/ytdl-org/youtube-dl/issues/30568#issue-1118238743 :
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.

https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024989514
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 ?

@chrizilla commented on GitHub (Jan 29, 2022): > https://github.com/ytdl-org/youtube-dl/issues/30568#issue-1118238743 : > 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. > https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024989514 > 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 ?

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 29, 2022):

Essentially https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024991879 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.

@dirkf commented on GitHub (Jan 29, 2022): Essentially https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024991879 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.

deekerman commented

Author

Owner

@dimitarvp commented on GitHub (Jan 29, 2022):

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.

@dimitarvp commented on GitHub (Jan 29, 2022): 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.

deekerman commented

Author

Owner

@spectrapulse commented on GitHub (Jan 29, 2022):

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.

@spectrapulse commented on GitHub (Jan 29, 2022): 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.

deekerman commented

Author

Owner

@Evernow commented on GitHub (Jan 29, 2022):

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.

@Evernow commented on GitHub (Jan 29, 2022): 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.

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jan 30, 2022):

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, https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025012255 said that youtube-dl's readme will be updated to mention yt-dlp

@gamer191 commented on GitHub (Jan 30, 2022): > 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, https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025012255 said that youtube-dl's readme will be updated to mention yt-dlp

deekerman commented

Author

Owner

@Earnestly commented on GitHub (Jan 30, 2022):

Who is @dirkf?

@Earnestly commented on GitHub (Jan 30, 2022): Who is @dirkf?

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 30, 2022):

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.

@dirkf commented on GitHub (Jan 30, 2022): Just your standard [Internet hound](https://i.kym-cdn.com/photos/images/original/000/427/569/bfa.jpg). 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.

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jan 30, 2022):

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

@gamer191 commented on GitHub (Jan 30, 2022): > 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

deekerman commented

Author

Owner

@Lesmiscore commented on GitHub (Jan 30, 2022):

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.

@Lesmiscore commented on GitHub (Jan 30, 2022): 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 30, 2022):

@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.

@dirkf commented on GitHub (Jan 30, 2022): @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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Jan 30, 2022):

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

@nocturn9x commented on GitHub (Jan 30, 2022): 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

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jan 30, 2022):

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

@gamer191 commented on GitHub (Jan 30, 2022): > 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

deekerman commented

Author

Owner

@Earnestly commented on GitHub (Jan 30, 2022):

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.

@Earnestly commented on GitHub (Jan 30, 2022): 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 30, 2022):

See https://github.com/ytdl-org for details of the yt-dl organisation and its current members.

@dirkf commented on GitHub (Jan 30, 2022): See https://github.com/ytdl-org for details of the yt-dl organisation and its current members.

deekerman commented

Author

Owner

@dimitarvp commented on GitHub (Jan 30, 2022):

"This organization has no public members. You must be a member to see who’s a part of this organization."

Not enlightening.

@dimitarvp commented on GitHub (Jan 30, 2022): "This organization has no public members. You must be a member to see who’s a part of this organization." Not enlightening.

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jan 30, 2022):

CC @dirkf

@gamer191 commented on GitHub (Jan 30, 2022): ![image (2)](https://user-images.githubusercontent.com/83270075/151722037-2900a944-b44f-4382-868e-2aec80d70aff.png) CC @dirkf

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 30, 2022):

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.

@dirkf commented on GitHub (Jan 30, 2022): 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.

deekerman commented

Author

Owner

@dimitarvp commented on GitHub (Jan 30, 2022):

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.

@dimitarvp commented on GitHub (Jan 30, 2022): > 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.

deekerman commented

Author

Owner

@spectrapulse commented on GitHub (Jan 30, 2022):

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.

@spectrapulse commented on GitHub (Jan 30, 2022): > > 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.

deekerman commented

Author

Owner

@garoto commented on GitHub (Jan 30, 2022):

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.

@garoto commented on GitHub (Jan 30, 2022): 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.

deekerman commented

Author

Owner

@kidonng commented on GitHub (Jan 31, 2022):

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).

@kidonng commented on GitHub (Jan 31, 2022): > 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](https://rg3.name/202011071352.html#_episode_a_new_home), 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).

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jan 31, 2022):

5/6 Good work, though more slashes than necessary.

@dirkf commented on GitHub (Jan 31, 2022): 5/6 Good work, though more slashes than necessary.

deekerman commented

Author

Owner

@Lesmiscore commented on GitHub (Jan 31, 2022):

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

@Lesmiscore commented on GitHub (Jan 31, 2022): 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](https://github.com/ytdl-org/youtube-dl/blob/master/devscripts/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

deekerman commented

See github.com/ytdl-org/youtube-dl@af9e72507e (commitcomment-65689220).

Author

Owner

@dirkf commented on GitHub (Jan 31, 2022):

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.

@dirkf commented on GitHub (Jan 31, 2022): See https://github.com/ytdl-org/youtube-dl/commit/af9e72507ea38e5ab3fa2751ed09ec88021260cb#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.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 1, 2022):

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!

@jxu commented on GitHub (Feb 1, 2022): > 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!

deekerman commented

Author

Owner

@rautamiekka commented on GitHub (Feb 1, 2022):

[...] without ever having contributed to the codebase themselves!

As equally invalid reason as "latest" is an invalid version.

@rautamiekka commented on GitHub (Feb 1, 2022): > [...] without ever having contributed to the codebase themselves! As equally invalid reason as "`latest`" is an invalid version.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 1, 2022):

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...

@nocturn9x commented on GitHub (Feb 1, 2022): > > 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...

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 1, 2022):

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.

@jxu commented on GitHub (Feb 1, 2022): 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 1, 2022):

I wondered, but followed the existing practice. Anyhow, this issue is a good honeypot for such discussions.

@dirkf commented on GitHub (Feb 1, 2022): I wondered, but followed the existing practice. Anyhow, this issue is a good honeypot for such discussions.

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 1, 2022):

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

@pukkandan commented on GitHub (Feb 1, 2022): > 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

deekerman commented

Author

Owner

@philcerf commented on GitHub (Feb 3, 2022):

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?

@philcerf commented on GitHub (Feb 3, 2022): 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?

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 3, 2022):

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.

@jxu commented on GitHub (Feb 3, 2022): 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 3, 2022):

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.

Also, "why is there only one Monopolies Commission"?

@dirkf commented on GitHub (Feb 3, 2022): 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. Also, "[why is there only one Monopolies Commission](https://www.newscientist.com/letter/mg15921488-500-joke-joke/)"?

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 3, 2022):

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.

Also, "why is there only one Monopolies Commission"?

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

@nocturn9x commented on GitHub (Feb 3, 2022): > 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. > > Also, "[why is there only one Monopolies Commission](https://www.newscientist.com/letter/mg15921488-500-joke-joke/)"? 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

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 3, 2022):

Except that both projects are being developed together, that's the plan. Nothing should go to waste.

@dirkf commented on GitHub (Feb 3, 2022): Except that both projects are being developed together, that's the plan. Nothing should go to waste.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 3, 2022):

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

@nocturn9x commented on GitHub (Feb 3, 2022): > 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

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 3, 2022):

So you propose youtube-dl as more compatible and yt-dlp as the development project? That is a possibility.

@jxu commented on GitHub (Feb 3, 2022): So you propose youtube-dl as more compatible and yt-dlp as the development project? That is a possibility.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 3, 2022):

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

@nocturn9x commented on GitHub (Feb 3, 2022): > 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

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 3, 2022):

I haven't kept up to date on how much development effort each project gets.

@jxu commented on GitHub (Feb 3, 2022): I haven't kept up to date on how much development effort each project gets.

deekerman commented

Author

Owner

@Evernow commented on GitHub (Feb 3, 2022):

@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.

@Evernow commented on GitHub (Feb 3, 2022): @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.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 3, 2022):

@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.

@jxu commented on GitHub (Feb 3, 2022): > @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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 3, 2022):

I'm definitely speaking out of self-interest, but not only that, as previously stated.

My position is settled for moment in line with https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024991879 and
https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025018207.

@dirkf commented on GitHub (Feb 3, 2022): I'm definitely speaking out of self-interest, but not only that, as previously stated. My position is settled for moment in line with https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024991879 and https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025018207.

deekerman commented

Author

Owner

@Evernow commented on GitHub (Feb 3, 2022):

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.

@Evernow commented on GitHub (Feb 3, 2022): > 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)](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1024991879) and [#30568 (comment)](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025018207). 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 3, 2022):

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.

@dirkf commented on GitHub (Feb 3, 2022): 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.

deekerman commented

Author

Owner

@garoto commented on GitHub (Feb 3, 2022):

Doing software development driven by public "polls" sounds like a really bad idea to me.

@garoto commented on GitHub (Feb 3, 2022): Doing software development driven by public "polls" sounds like a really bad idea to me.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 3, 2022):

That comes with the territory when there's not a reliable set of core developers.

@jxu commented on GitHub (Feb 3, 2022): That comes with the territory when there's not a reliable set of core developers.

deekerman commented

=> https://github.com/JulienPalard/python-versions

Author

Owner

@JulienPalard commented on GitHub (Feb 3, 2022):

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:

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.

@JulienPalard commented on GitHub (Feb 3, 2022): 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/raw/main/python-versions-pct.png)](https://github.com/JulienPalard/python-versions) => 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 3, 2022):

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 specifier
memoryview
argparse
logging.config.dictConfig
dict viewkeys(), 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_length method of int and long
@classmethod and @staticmethod wrapped 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?

@dirkf commented on GitHub (Feb 3, 2022): 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](https://docs.python.org/2.7/whatsnew/2.7.html) 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 specifier * `memoryview` * `argparse` * `logging.config.dictConfig` * `dict` `viewkeys()`, `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_length` method of `int` and `long` * `@classmethod` and `@staticmethod` wrapped 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?

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 3, 2022):

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

@pukkandan commented on GitHub (Feb 3, 2022): 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

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Feb 4, 2022):

Just wondering, does YouTube-DL have any plans to drop official support for avconv, like yt-dlp did? (Personally, I don’t use avconv)

@gamer191 commented on GitHub (Feb 4, 2022): Just wondering, does YouTube-DL have any plans to drop official support for avconv, like yt-dlp did? (Personally, I don’t use avconv)

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Feb 4, 2022):

name youtube-dl is more catchy and well-known

and thus maybe more exposed to DCMA action by Google/youtube ?

@chrizilla commented on GitHub (Feb 4, 2022): > name youtube-dl is more catchy and well-known and thus maybe more exposed to DCMA action by Google/youtube ?

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Feb 4, 2022):

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 request to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position request has 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 of request'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.

@EvanCarroll commented on GitHub (Feb 4, 2022): 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](https://github.com/request/request/issues/3142) > The best thing for these new modules is for `request` to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position `request` has 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 of `request`'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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 4, 2022):

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 request to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position request has 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 of request'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

@nocturn9x commented on GitHub (Feb 4, 2022): > 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](https://github.com/request/request/issues/3142) > > > The best thing for these new modules is for `request` to slowly fade away, eventually becoming just another memory of that legacy stack. Taking the position `request` has 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 of `request`'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

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

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.

@dirkf commented on GitHub (Feb 4, 2022): >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_.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

dict comprehensions. They currently use the pattern dict((k, v) for ...)

Whereas the newer non-2.6 version would be {(k, v) for ...}

@dirkf commented on GitHub (Feb 4, 2022): > dict comprehensions. They currently use the pattern `dict((k, v) for ...)` Whereas the newer non-2.6 version would be `{(k, v) for ...}`

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 4, 2022):

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.

@FranciscoPombal commented on GitHub (Feb 4, 2022): 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](https://bugs.launchpad.net/calibre/+bug/1714107/comments/1). 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

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.

Or, https://www.youtube.com/watch?v=vmMls5bNOPw.

@dirkf commented on GitHub (Feb 4, 2022): 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. Or, https://www.youtube.com/watch?v=vmMls5bNOPw.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 4, 2022):

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.

Or, https://www.youtube.com/watch?v=vmMls5bNOPw.

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!!"

@nocturn9x commented on GitHub (Feb 4, 2022): > 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. > > Or, https://www.youtube.com/watch?v=vmMls5bNOPw. > 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!!"

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

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.

@dirkf commented on GitHub (Feb 4, 2022): 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.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 4, 2022):

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: https://github.com/request/request/issues/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".

@FranciscoPombal commented on GitHub (Feb 4, 2022): 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: https://github.com/request/request/issues/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".

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 4, 2022):

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.

@FranciscoPombal commented on GitHub (Feb 4, 2022): > 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.

deekerman commented

Author

Owner

@fcore117 commented on GitHub (Feb 4, 2022):

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:

@fcore117 commented on GitHub (Feb 4, 2022): 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: ![istockphoto-1087648834-612x612](https://user-images.githubusercontent.com/1313813/152538338-71a966d1-2184-4e19-8858-1e908afbdd49.jpg)

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 4, 2022):

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

@pukkandan commented on GitHub (Feb 4, 2022): > * 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

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

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.

@dirkf commented on GitHub (Feb 4, 2022): >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](https://xkcd.com/2347/) with no support from businesses that rely on him (examples [passim](https://www.reddit.com/r/xkcd/comments/qc178e/xkcd_2347_dependency_turns_out_to_be_true_and_the/)), 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.

deekerman commented

Author

Owner

@spectrapulse commented on GitHub (Feb 4, 2022):

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.

@spectrapulse commented on GitHub (Feb 4, 2022): > > 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](https://xkcd.com/2347/) with no support from businesses that rely on him (examples [passim](https://www.reddit.com/r/xkcd/comments/qc178e/xkcd_2347_dependency_turns_out_to_be_true_and_the/)), 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.

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 4, 2022):

Are people coming here from this mistitled post or one of its many clones? 🤔

@pukkandan commented on GitHub (Feb 4, 2022): Are people coming here from [this mistitled post](https://developers.slashdot.org/story/22/01/30/003205/youtube-dl-forks-to-continue-supporting-older-versions-of-python) or one of its many clones? 🤔

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 4, 2022):

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.

@jxu commented on GitHub (Feb 4, 2022): > It's bad enough that [one guy in Nebraska supports the whole Internet](https://xkcd.com/2347/) with no support from businesses that rely on him (examples [passim](https://www.reddit.com/r/xkcd/comments/qc178e/xkcd_2347_dependency_turns_out_to_be_true_and_the/)), 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 4, 2022):

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.

@dirkf commented on GitHub (Feb 4, 2022): 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](https://www.jwz.org/blog/2021/10/finally-got-my-emacs-setup-just-how-i-like-it-6/) and don't want to spend time redoing it.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 4, 2022):

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 :)

@nocturn9x commented on GitHub (Feb 4, 2022): > >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](https://xkcd.com/2347/) with no support from businesses that rely on him (examples [passim](https://www.reddit.com/r/xkcd/comments/qc178e/xkcd_2347_dependency_turns_out_to_be_true_and_the/)), 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 :)

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (Feb 4, 2022):

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 commented on GitHub (Feb 4, 2022): 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.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Feb 4, 2022):

@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.

@EvanCarroll commented on GitHub (Feb 4, 2022): @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.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 4, 2022):

Also there are unofficial python 3 32 bit binaries that should work.

@jxu commented on GitHub (Feb 4, 2022): Also there are unofficial python 3 32 bit binaries that should work.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 4, 2022):

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...

@FranciscoPombal commented on GitHub (Feb 4, 2022): >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](https://xkcd.com/2347/) ... 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...

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 4, 2022):

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.

@nocturn9x commented on GitHub (Feb 4, 2022): > >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](https://xkcd.com/2347/) ... > > 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.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 4, 2022):

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.

@jxu commented on GitHub (Feb 4, 2022): > 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.

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (Feb 4, 2022):

@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!

@Rekrullurker commented on GitHub (Feb 4, 2022): @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!

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 4, 2022):

@Rekrullurker

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.

@FranciscoPombal commented on GitHub (Feb 4, 2022): @Rekrullurker 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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 5, 2022):

@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

@nocturn9x commented on GitHub (Feb 5, 2022): > @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

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 5, 2022):

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.

@dirkf commented on GitHub (Feb 5, 2022): 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](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1030018047). 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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 5, 2022):

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.

@nocturn9x commented on GitHub (Feb 5, 2022): > 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](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1030018047). 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 5, 2022):

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.

@dirkf commented on GitHub (Feb 5, 2022): 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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 5, 2022):

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

@nocturn9x commented on GitHub (Feb 5, 2022): > 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

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 5, 2022):

Obviously not, as illustrated above.

@dirkf commented on GitHub (Feb 5, 2022): Obviously not, as illustrated above.

deekerman commented

Author

Owner

@jxu commented on GitHub (Feb 5, 2022):

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.

@jxu commented on GitHub (Feb 5, 2022): > 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.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Feb 5, 2022):

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.

@EvanCarroll commented on GitHub (Feb 5, 2022): > 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.

deekerman commented

Author

Owner

@arrowgent commented on GitHub (Feb 6, 2022):

best of luck moving forward continuing to maintain youtube-dl

@arrowgent commented on GitHub (Feb 6, 2022): best of luck moving forward continuing to maintain youtube-dl

deekerman commented

Author

Owner

@Zirro commented on GitHub (Feb 6, 2022):

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.

@Zirro commented on GitHub (Feb 6, 2022): 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.

deekerman commented

Author

Owner

@FranciscoPombal commented on GitHub (Feb 7, 2022):

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.

@FranciscoPombal commented on GitHub (Feb 7, 2022): > 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](https://www.gnu.org/philosophy/right-to-read.html). 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.

deekerman commented

Author

Owner

@nocturn9x commented on GitHub (Feb 7, 2022):

[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!!!!"

@nocturn9x commented on GitHub (Feb 7, 2022): > [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!!!!"

deekerman commented

Author

Owner

@Jonta commented on GitHub (Feb 7, 2022):

@dirkf Would you be open to a Readme-PR, which would tell people about yt-dlp? =)

@Jonta commented on GitHub (Feb 7, 2022): @dirkf Would you be open to a Readme-PR, which would tell people about yt-dlp? =)

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 7, 2022):

... 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 commented on GitHub (Feb 7, 2022): >... 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](https://github.com/yt-dlp/yt-dlp/issues/2565#issuecomment-1026582114). 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](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1030001434). So your proposal would mean three projects instead of two: I don't think that would be an improvement. Also, [what @Zirro said](https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1030932099). >... > 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.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 7, 2022):

@dirkf Would you be open to a Readme-PR, which would tell people about yt-dlp? =)

See https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025012255. By all means have a go: your text may be better than what I was going to include in the next release.

@dirkf commented on GitHub (Feb 7, 2022): > @dirkf Would you be open to a Readme-PR, which would tell people about yt-dlp? =) See https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025012255. By all means have a go: your text may be better than what I was going to include in the next release.

deekerman commented

PR to include mention of yt-dlp in Readme is #30613

Author

Owner

@Jonta commented on GitHub (Feb 7, 2022):

@Jonta commented on GitHub (Feb 7, 2022): [PR to include mention of yt-dlp in Readme is #30613](https://github.com/ytdl-org/youtube-dl/pull/30613)

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Feb 10, 2022):

example of ytdl-ytdlp-redundancy ?
https://github.com/yt-dlp/yt-dlp/issues/2702#issuecomment-1034326815

@chrizilla commented on GitHub (Feb 10, 2022): example of ytdl-ytdlp-redundancy ? https://github.com/yt-dlp/yt-dlp/issues/2702#issuecomment-1034326815

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 10, 2022):

No, I believe the patch applies to both versions of the extractor as they are actually identical. If I get around to committing it I expect yt-dlp will pick it up, or vice versa. Either way, whatever hard work was needed is already done.

@dirkf commented on GitHub (Feb 10, 2022): No, I believe the patch applies to both versions of the extractor as they are actually identical. If I get around to committing it I expect yt-dlp will pick it up, or vice versa. Either way, whatever hard work was needed is already done.

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Feb 10, 2022):

I meant the overhead of reporting&handling the same issue twice:
both on ytdl #30458 and ytdlp #2702

@chrizilla commented on GitHub (Feb 10, 2022): I meant the overhead of reporting&handling the same issue twice: both on ytdl [#30458](https://github.com/ytdl-org/youtube-dl/issues/30458) and ytdlp [#2702](https://github.com/yt-dlp/yt-dlp/issues/2702)

deekerman commented

Author

Owner

@Jonta commented on GitHub (Feb 11, 2022):

Seems like that should be coordinated

If youtube-dl and yt-dlp should use the same code for site support

I suggest just 1 of the 2 projects get all site broken/site support requests directed to it

youtube-dl currently has 801 open issues with the label site-support-request, which is >2.7x as many as

yt-dlp's issues tagged with site-bug (131)
site-enhancement (67) and
site-request (97)
combined (295. Not counting possible overlaps)

I don't know how accurate these numbers are, but my bet's on it being more work to move youtube-dl's issues to yt-dlp, than the other way around

If they should not use the same code for site support

I suggest a separate, 3rd issue tracker for site support/bug/enhancement requests

But hey

Maybe the sites that youtube-dl users want support for will diverge significantly from those yt-dlp users want support for. Maybe it's already the case. In which case, coordination isn't worth it

Note: I am not really familiar with the projects

@Jonta commented on GitHub (Feb 11, 2022): Seems like that should be coordinated **If youtube-dl and yt-dlp should use the same code for site support** I suggest just 1 of the 2 projects get all site broken/site support requests directed to it youtube-dl currently has [801 open issues with the label site-support-request](https://github.com/ytdl-org/youtube-dl/labels/site-support-request), which is >2.7x as many as - [yt-dlp's issues tagged with site-bug (131)](https://github.com/yt-dlp/yt-dlp/labels/site-bug) - [site-enhancement (67)](https://github.com/yt-dlp/yt-dlp/labels/site-enhancement) and - [site-request (97)](https://github.com/yt-dlp/yt-dlp/labels/site-request) - _combined_ (295. Not counting possible overlaps) I don't know how accurate these numbers are, but my bet's on it being more work to move youtube-dl's issues to yt-dlp, than the other way around **If they should not use the same code for site support** I suggest a separate, 3rd issue tracker for site support/bug/enhancement requests **But hey** Maybe the sites that youtube-dl users want support for will diverge significantly from those yt-dlp users want support for. Maybe it's already the case. In which case, coordination isn't worth it Note: I am not really familiar with the projects

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 11, 2022):

I meant the overhead of reporting&handling the same issue twice:

That's really a relic of the interregnum. If the fix in the issue had been committed in yt-dl at the time, it would have been more visible. The maintainers are more likely to see commits than all issues in the other project.

As some of the extractors, not to mention the core processing, differ significantly between yt-dl and yt-dlp, it would only be confusing to report issues in one place.

@dirkf commented on GitHub (Feb 11, 2022): > I meant the overhead of reporting&handling the same issue twice: That's really a relic of the interregnum. If the fix in the issue had been committed in yt-dl at the time, it would have been more visible. The maintainers are more likely to see commits than all issues in the other project. As some of the extractors, not to mention the core processing, differ significantly between yt-dl and yt-dlp, it would only be confusing to report issues in one place.

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Feb 12, 2022):

@dirkf good explanation, thank you

@chrizilla commented on GitHub (Feb 12, 2022): @dirkf good explanation, thank you

deekerman commented

Author

Owner

@issues101 commented on GitHub (Feb 16, 2022):

It's not the Python version. yt-dlp doesn't work under Windows XP. That's my complaint.

@issues101 commented on GitHub (Feb 16, 2022): It's not the Python version. yt-dlp doesn't work under Windows XP. That's my complaint.

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 16, 2022):

It's not the Python version. yt-dlp doesn't work under Windows XP

Same thing. The last python version that works for XP is 3.4

@pukkandan commented on GitHub (Feb 16, 2022): > It's not the Python version. yt-dlp doesn't work under Windows XP Same thing. The last python version that works for XP is 3.4

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Feb 16, 2022):

It's not the Python version. yt-dlp doesn't work under Windows XP. That's my complaint.

just gonna ask who is using windows xp with youtube-dl in 2022
it is dead

@MrRawes commented on GitHub (Feb 16, 2022): > It's not the Python version. yt-dlp doesn't work under Windows XP. That's my complaint. just gonna ask who is using windows xp with youtube-dl in 2022 [it is dead](https://upload.wikimedia.org/wikipedia/en/timeline/qmsdns1kt0dveowm64te5el0ev5jksp.png)

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (Feb 16, 2022):

Actually, I have an old system that still has XP on it.

Now, I know I'm going to get people asking why, so...

I don't have the money to buy a new computer. Even if I did, I don't really want Windows 10/11 with its spyware and forced updates. I know absolutely nothing about Linux and don't really want to learn a whole new OS and then not be able to run some programs that I've come to depend on. I could install Windows 7 on this system (yes, I know Windows 7 is now classified as obsolete), but I don't have a copy of Windows 7 and even if I did, I really don't want to nuke a system that I use daily and start over from scratch, because if I run into problems, then I'm left scrambling to try and configure an old system into something usable.

So for the time being, until I can afford to get something newer, this is what I have.

And for all the FUD about XP being outdated, web-based applications (browsers, YouTube-DL) are really the only things that give me problems. I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email (at least those standards don't change at the drop of a hat), view images, watch videos, upload/download files, etc.

I can still use the last version of YouTube-DL, although the downloads are very slow. I wrote a script to feed the download URLs to Internet Download Accelerator. I only get a max of about 400-500K/s, but it's better than the snail's pace that YouTube-DL alone gives me. Oh, I also can't download age-restricted videos. I tried the cookie-dump method, but I could never get it to work.

@Rekrullurker commented on GitHub (Feb 16, 2022): Actually, I have an old system that still has XP on it. Now, I know I'm going to get people asking why, so... I don't have the money to buy a new computer. Even if I did, I don't really want Windows 10/11 with its spyware and forced updates. I know absolutely nothing about Linux and don't really want to learn a whole new OS and then not be able to run some programs that I've come to depend on. I could install Windows 7 on this system (yes, I know Windows 7 is now classified as obsolete), but I don't have a copy of Windows 7 and even if I did, I really don't want to nuke a system that I use daily and start over from scratch, because if I run into problems, then I'm left scrambling to try and configure an old system into something usable. So for the time being, until I can afford to get something newer, this is what I have. And for all the FUD about XP being outdated, web-based applications (browsers, YouTube-DL) are really the only things that give me problems. I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email (at least those standards don't change at the drop of a hat), view images, watch videos, upload/download files, etc. I can still use the last version of YouTube-DL, although the downloads are very slow. I wrote a script to feed the download URLs to Internet Download Accelerator. I only get a max of about 400-500K/s, but it's better than the snail's pace that YouTube-DL alone gives me. Oh, I also can't download age-restricted videos. I tried the cookie-dump method, but I could never get it to work.

deekerman commented

Author

Owner

@bersbersbers commented on GitHub (Feb 17, 2022):

Actually, I have an old system that still has XP on it.
[...]
I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email

Wow - the oldest Chrome version supported on Windows XP is Chrome 49 and was released in 2016. I won't even start looking for the number of serious CVEs reported since then, but I certainly applaud your courage to log into your email account on an 8-years-expired OS and a maybe 6-years old browser.

Anyway, why do you consider this an important data point in the decision process on whether to support Python 2 in the coming years? Don't you think that you are maintaining an extremely rare setup the existence of which should not impact (read: impede) development of youtube-dl? I for one would not ask anyone to base their decision on what software I freely decide to use - there is a lot of "I don't want to"s in your post.

@bersbersbers commented on GitHub (Feb 17, 2022): > Actually, I have an old system that still has XP on it. > [...] > I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email Wow - the oldest Chrome version supported on Windows XP is Chrome 49 and was released in 2016. I won't even start looking for the number of serious CVEs reported since then, but I certainly applaud your courage to log into your email account on an 8-years-expired OS and a maybe 6-years old browser. Anyway, why do you consider this an important data point in the decision process on whether to support Python 2 in the coming years? Don't you think that you are maintaining an extremely rare setup the existence of which should not impact (read: impede) development of youtube-dl? I for one would not ask anyone to base their decision on what software I *freely decide* to use - there is a lot of "I don't want to"s in your post.

deekerman commented

Author

Owner

@Lee-Carre commented on GitHub (Feb 17, 2022):

new management

Given the planned changes (modernising the release process) I've read about, and after other priorities are dealt with, a suggestion: enable Discussions in this repo.

They would be a better place for users to ask questions, instead of issues, for starters. Particularly since answers can be marked as such & up-voted.

Conversations are partially-threaded, so discussion of ideas should be easier.

I've seen this work well in other busy repos.

Though, personally, I'm quite happy to wait until after the forthcoming release.

@Lee-Carre commented on GitHub (Feb 17, 2022): > new management Given the planned changes (modernising the release process) I've read about, and after other priorities are dealt with, a **suggestion: enable Discussions** in this repo. They would be a better place for users to ask questions, instead of issues, for starters. Particularly since answers can be marked as such & up-voted. Conversations are partially-threaded, so discussion of ideas should be easier. I've seen this work well in other busy repos. Though, personally, I'm quite happy to wait until after the forthcoming release.

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Feb 17, 2022):

a suggestion: enable Discussions in this repo.

In yt-dlp I had to disable discussions because they were unmanagable. Some of the difficulties I had:

You can't properly "close" discussions (questions can be marked answered ig)
Many people abuse it as a way to just bypass the issue template
They are far less discoverable. Most people are more used to issues
Github's "mentioned this issue" labels dont appear for discussions, making it difficult to follow inter-issue conversations
Users have to search in both discussions and issues separately to check for duplicates. Often it is not clear where something should belong

Not saying this is a bad idea, just sharing my experience. Maybe dirkf will find it more usefull than I did

@pukkandan commented on GitHub (Feb 17, 2022): > a suggestion: enable Discussions in this repo. In yt-dlp I had to disable discussions because they were unmanagable. Some of the difficulties I had: 1. You can't properly "close" discussions (questions can be marked answered ig) 2. Many people abuse it as a way to just bypass the issue template 3. They are far less discoverable. Most people are more used to issues 4. Github's "mentioned this issue" labels dont appear for discussions, making it difficult to follow inter-issue conversations 5. Users have to search in both discussions and issues separately to check for duplicates. Often it is not clear where something should belong Not saying this is a bad idea, just sharing my experience. Maybe dirkf will find it more usefull than I did

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 17, 2022):

Wow - the oldest Chrome version supported on Windows XP is Chrome 49 and was released in 2016.

Plainly @Rekrullurker is using some other browser and an actual email program, probably Mozilla-based, rather than the one true browser. One might wish that all the people, not least in the third world, with XP systems would get with Linux, but the world is as it is.

...Not saying [Discussions] is a bad idea, just sharing my experience.

I'm not being enthused to try it.

@dirkf commented on GitHub (Feb 17, 2022): >Wow - the oldest Chrome version supported on Windows XP is Chrome 49 and was released in 2016. Plainly @Rekrullurker is using some other browser and an actual email program, probably Mozilla-based, rather than the _one true browser_. One might wish that all the people, not least in the third world, with XP systems would get with Linux, but the world is as it is. >...Not saying [Discussions] is a bad idea, just sharing my experience. I'm not being enthused to try it.

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (Feb 17, 2022):

@bersbersbers - I was answering the question about who still uses XP and then elaborated because every time I mention that I still have XP, I inevitably get asked why.

@Rekrullurker commented on GitHub (Feb 17, 2022): @bersbersbers - I was answering the question about who still uses XP and then elaborated because every time I mention that I still have XP, I inevitably get asked why.

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Feb 17, 2022):

Actually, I have an old system that still has XP on it.

Now, I know I'm going to get people asking why, so...

I don't have the money to buy a new computer. Even if I did, I don't really want Windows 10/11 with its spyware and forced updates. I know absolutely nothing about Linux and don't really want to learn a whole new OS and then not be able to run some programs that I've come to depend on. I could install Windows 7 on this system (yes, I know Windows 7 is now classified as obsolete), but I don't have a copy of Windows 7 and even if I did, I really don't want to nuke a system that I use daily and start over from scratch, because if I run into problems, then I'm left scrambling to try and configure an old system into something usable.

So for the time being, until I can afford to get something newer, this is what I have.

And for all the FUD about XP being outdated, web-based applications (browsers, YouTube-DL) are really the only things that give me problems. I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email (at least those standards don't change at the drop of a hat), view images, watch videos, upload/download files, etc.

I can still use the last version of YouTube-DL, although the downloads are very slow. I wrote a script to feed the download URLs to Internet Download Accelerator. I only get a max of about 400-500K/s, but it's better than the snail's pace that YouTube-DL alone gives me. Oh, I also can't download age-restricted videos. I tried the cookie-dump method, but I could never get it to work.

DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT

@MrRawes commented on GitHub (Feb 17, 2022): > Actually, I have an old system that still has XP on it. > > Now, I know I'm going to get people asking why, so... > > I don't have the money to buy a new computer. Even if I did, I don't really want Windows 10/11 with its spyware and forced updates. I know absolutely nothing about Linux and don't really want to learn a whole new OS and then not be able to run some programs that I've come to depend on. I could install Windows 7 on this system (yes, I know Windows 7 is now classified as obsolete), but I don't have a copy of Windows 7 and even if I did, I really don't want to nuke a system that I use daily and start over from scratch, because if I run into problems, then I'm left scrambling to try and configure an old system into something usable. > > So for the time being, until I can afford to get something newer, this is what I have. > > And for all the FUD about XP being outdated, web-based applications (browsers, YouTube-DL) are really the only things that give me problems. I can't run the latest web browsers and more and more websites are broken on older ones (who knew that displaying text and graphics required a state of the art web browser...). Sure, I can't run the latest versions of emulators, but the ones I have still work fine, I can still send and receive email (at least those standards don't change at the drop of a hat), view images, watch videos, upload/download files, etc. > > I can still use the last version of YouTube-DL, although the downloads are very slow. I wrote a script to feed the download URLs to Internet Download Accelerator. I only get a max of about 400-500K/s, but it's better than the snail's pace that YouTube-DL alone gives me. Oh, I also can't download age-restricted videos. I tried the cookie-dump method, but I could never get it to work. DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT DUAL BOOT

deekerman commented

Author

Owner

@chrizilla commented on GitHub (Feb 17, 2022):

Given the planned changes (modernising the release process) I've read about, and after other priorities are dealt with, a suggestion: enable Discussions in this repo. […]

Conversations are partially-threaded, so discussion of ideas should be easier.

I've seen this work well in other busy repos.

👍 +1

@chrizilla commented on GitHub (Feb 17, 2022): > Given the planned changes (modernising the release process) I've read about, and after other priorities are dealt with, a **suggestion: enable Discussions** in this repo. […] > > Conversations are partially-threaded, so discussion of ideas should be easier. > > I've seen this work well in other busy repos. 👍 +1

deekerman commented

Author

Owner

@dirkf commented on GitHub (Feb 17, 2022):

Based on https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1043020453 (and I was aware of that situation), I suggest that a convention of starting (or renaming) an issue prefixed by 'Discussion: ', like 'Discussion: moving project maintenance to a mailing list like the Linux kernel', would address the need; there could also be a Discussion label.

@dirkf commented on GitHub (Feb 17, 2022): Based on https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1043020453 (and I was aware of that situation), I suggest that a convention of starting (or renaming) an issue prefixed by 'Discussion: ', like 'Discussion: moving project maintenance to a mailing list like the Linux kernel', would address the need; there could also be a Discussion label.

deekerman commented

Author

Owner

@Lee-Carre commented on GitHub (Feb 17, 2022):

@MrRawes

DUAL BOOT [repeated ad infinitum(!)]

See Rick Moen's

@Lee-Carre commented on GitHub (Feb 17, 2022): @MrRawes > DUAL BOOT [repeated ad infinitum(!)] See Rick Moen's * [I want to try \[GNU+\]Linux, but keep my existing Windows setup (and keep all its files intact). What's the easiest way to do this? Should I use Partition Magic \[and/or **dual boot**\]?](http://linuxmafia.com/~rick/faq/kicking.html#partition) * [Why isn't \[GNU+\]Linux doing more to help “Joe User”?](http://linuxmafia.com/~rick/faq/kicking.html#joeuser)

deekerman commented

Author

Owner

@Lee-Carre commented on GitHub (Feb 17, 2022):

You can't properly "close" discussions (questions can be marked answered ig)

github/feedback/discussions #3097 “Close discussions” [200 up-votes]

Many people abuse it as a way to just bypass the issue template

github/feedback/discussion #2838 “Templates (like issue templates) for discussions” [100+ up-votes]

They are far less discoverable. Most people are more used to issues

Somewhat related: github/feedback/discussion #2861 “Convert Discussion into Issue” [120+ up-votes]

Though, this applies to anything new. Chicken-and-egg problem.

Github's "mentioned this issue" labels dont appear for discussions, making it difficult to follow inter-issue conversations

github/feedback/discussion #2971 “Discussion should be able to link to issue and versa visa, like issues to issues.” [50+ up-votes]

Users have to search in both discussions and issues separately to check for duplicates. Often it is not clear where something should belong

github/feedback/discussion #4436 “Improve github search” which basically points to Github search sucks (and how it could be better). [50+ up-votes]

@Lee-Carre commented on GitHub (Feb 17, 2022): > 1. You can't properly "close" discussions (questions can be marked answered ig) [github/feedback/discussions #3097 “Close discussions”](/github/feedback/discussions/3097) [200 up-votes] > 2. Many people abuse it as a way to just bypass the issue template [github/feedback/discussion #2838 “Templates (like issue templates) for discussions”](/github/feedback/discussions/2838) [100+ up-votes] > 3. They are far less discoverable. Most people are more used to issues Somewhat related: [github/feedback/discussion #2861 “Convert Discussion into Issue”](/github/feedback/discussions/2861) [120+ up-votes] Though, this applies to anything new. Chicken-and-egg problem. > 4. Github's "mentioned this issue" labels dont appear for discussions, making it difficult to follow inter-issue conversations [github/feedback/discussion #2971 “Discussion should be able to link to issue and versa visa, like issues to issues.”](/github/feedback/discussions/2971) [50+ up-votes] > 5. Users have to search in both discussions and issues separately to check for duplicates. Often it is not clear where something should belong [github/feedback/discussion #4436 “Improve github search”](/github/feedback/discussions/4436) which basically points to [Github search sucks (and how it could be better)](/isaacs/github/issues/908). [50+ up-votes]

deekerman commented

Author

Owner

@issues101 commented on GitHub (Mar 9, 2022):

People keep asking why anybody would use Windows XP. It's off topic, of course, but since there are so many inquiries, here are a few comments...

Personally, I don't understand why anybody would use Windows 7 and above.
The entire XP installation is 1.5 GB. It fits on a FAT partition, which is noticeably faster than NTFS. It takes literally three minutes to make a backup copy of the entire operating system or restore the entire system. Try to do that in Windows 7, where files are locked.
The user interface in Windows 7 and above is grotesque. You have to use the mouse where in Windows XP you could use keyboard. What takes five minutes to accomplish in Windows XP, takes half an hour in Windows 7.
When you try to copy and replace a file, Windows 7 Explorer presents you with a dialog box that is ten times more convoluted than Windows XP dialog box, which had simple "Yes" / "No" / "Yes to All" buttons. You have to spend ten minutes finding you way around Windows 7 dialog box.
Windows 7 Explorer has a very serious design flaw--but let me stop here, before this gets too long...

@issues101 commented on GitHub (Mar 9, 2022): People keep asking why anybody would use Windows XP. It's off topic, of course, but since there are so many inquiries, here are a few comments... 1. Personally, I don't understand why anybody would use Windows 7 and above. 2. The entire XP installation is 1.5 GB. It fits on a FAT partition, which is noticeably faster than NTFS. It takes literally three minutes to make a backup copy of the entire operating system or restore the entire system. Try to do that in Windows 7, where files are locked. 3. The user interface in Windows 7 and above is grotesque. You have to use the mouse where in Windows XP you could use keyboard. What takes five minutes to accomplish in Windows XP, takes half an hour in Windows 7. 4. When you try to copy and replace a file, Windows 7 Explorer presents you with a dialog box that is ten times more convoluted than Windows XP dialog box, which had simple "Yes" / "No" / "Yes to All" buttons. You have to spend ten minutes finding you way around Windows 7 dialog box. 5. Windows 7 Explorer has a very serious design flaw--but let me stop here, before this gets too long...

deekerman commented

Author

Owner

@spectrapulse commented on GitHub (Mar 10, 2022):

I don't see any justified reason why to keep using an EOL operating system.
And none of the ones that have been mentioned are valid either.

Second, this Discussion doesn't belong here. It shouldn't be relevant. If
you choose to use EOL software you shouldn't expect it to be supported just
because you don't agree with the choices made in later revisions.

On Thu, 10 Mar 2022 at 05:00, issues101 @.***> wrote:

People keep asking why anybody would use Windows XP. It's off topic, of
course, but since there are so many inquiries, here are a few comments...

Personally, I don't understand why anybody would use Windows 7 and
above.

The entire XP installation is 1.5 GB. It fits on a FAT partition,
which is noticeably faster than NTFS. It takes literally three minutes to
make a backup copy of the entire operating system or restore the entire
system. Try to do that in Windows 7, where files are locked.

The user interface in Windows 7 and above is grotesque. You have to
use the mouse where in Windows XP you could use keyboard. What takes five
minutes to accomplish in Windows XP, takes half an hour in Windows 7.

When you try to copy and replace a file, Windows 7 Explorer
presents you with a dialog box that is ten times more convoluted than
Windows XP dialog box, which had simple "Yes" / "No" / "Yes to All"
buttons. You have to spend ten minutes finding you way around Windows 7
dialog box.

Windows 7 Explorer has a very serious design flaw--but let me stop
here, before this gets too long...

—
Reply to this email directly, view it on GitHub
https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1063640296,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEZS6STICLJPKGHUJKUB4EDU7FXXJANCNFSM5NC7EC7A
.
You are receiving this because you commented.Message ID:
@.***>

@spectrapulse commented on GitHub (Mar 10, 2022): I don't see any justified reason why to keep using an EOL operating system. And none of the ones that have been mentioned are valid either. Second, this Discussion doesn't belong here. It shouldn't be relevant. If you choose to use EOL software you shouldn't expect it to be supported just because you don't agree with the choices made in later revisions. On Thu, 10 Mar 2022 at 05:00, issues101 ***@***.***> wrote: > People keep asking why anybody would use Windows XP. It's off topic, of > course, but since there are so many inquiries, here are a few comments... > > 1. Personally, I don't understand why anybody would use Windows 7 and > above. > 2. The entire XP installation is 1.5 GB. It fits on a FAT partition, > which is noticeably faster than NTFS. It takes literally three minutes to > make a backup copy of the entire operating system or restore the entire > system. Try to do that in Windows 7, where files are locked. > 3. The user interface in Windows 7 and above is grotesque. You have to > use the mouse where in Windows XP you could use keyboard. What takes five > minutes to accomplish in Windows XP, takes half an hour in Windows 7. > 4. When you try to copy and replace a file, Windows 7 Explorer > presents you with a dialog box that is ten times more convoluted than > Windows XP dialog box, which had simple "Yes" / "No" / "Yes to All" > buttons. You have to spend ten minutes finding you way around Windows 7 > dialog box. > 5. Windows 7 Explorer has a very serious design flaw--but let me stop > here, before this gets too long... > > — > Reply to this email directly, view it on GitHub > <https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1063640296>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEZS6STICLJPKGHUJKUB4EDU7FXXJANCNFSM5NC7EC7A> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

deekerman commented

Author

Owner

@forresthopkinsa commented on GitHub (Mar 15, 2022):

Ultimately, youtube-dl is a well-established project with a long history, and I doubt that most of its users have ever even heard of the fork. It's neat that YTDLP has some cool extra features but, like with Debian and Ubuntu, some of us would prefer the upstream. Thank you dirkf for taking up the torch.

@forresthopkinsa commented on GitHub (Mar 15, 2022): Ultimately, youtube-dl is a well-established project with a long history, and I doubt that most of its users have ever even heard of the fork. It's neat that YTDLP has some cool extra features but, like with Debian and Ubuntu, some of us would prefer the upstream. Thank you dirkf for taking up the torch.

deekerman commented

https://www.activestate.com/products/python/python-2-end-of-life-security-updates/

Author

Owner

@EvanCarroll commented on GitHub (Mar 15, 2022):

@forresthopkinsa The fork is called yt-dlp; that most of the users haven't heard of the fork is exactly why this project should,

Update the README to point to the fork at the very top in bold.
Archive itself.

It's not even like they're keeping up. Look at the commit history of the two projects for a representation of health.

Alas, can you imagine wasting your time on these kinds of commits reverting for python2 compatibility, a dead EOL, and insecure language.

And by insecure, I mean python.org isn't patching these releases anymore. It's basically Debian/Ubuntu/ActiveState that are your only source for secure Python2. And not even really. Just scroll down to Fix in Progress, Fix Pending and you can see exploits available now for things running Python2.

@EvanCarroll commented on GitHub (Mar 15, 2022): @forresthopkinsa The fork is called `yt-dlp`; that most of the users haven't heard of the fork is **exactly** why this project should, 1. Update the README to point to the fork at the very top in bold. 2. Archive itself. It's not even like they're keeping up. Look at the commit history of the two projects for a representation of health. * https://github.com/yt-dlp/yt-dlp/commits/master * https://github.com/ytdl-org/youtube-dl/commits/master Alas, can you imagine wasting your time on these kinds of commits reverting for python2 compatibility, a dead EOL, and insecure language. * https://github.com/ytdl-org/youtube-dl/commit/d02064218be76eba6350a13ccbbc473b1b439570 * https://github.com/ytdl-org/youtube-dl/commit/85bf26c1d01f94b83476703e5c70022f01164ccf And by insecure, I mean python.org isn't patching these releases anymore. It's basically Debian/Ubuntu/ActiveState that are your only source for secure Python2. And not even really. Just scroll down to Fix in Progress, Fix Pending and you can see exploits available now for things running Python2. https://www.activestate.com/products/python/python-2-end-of-life-security-updates/

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Mar 31, 2022):

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.

CORRECTION: yt-dlp does not require an up-to-date python version, the minimum python version is 3.6 first released in late 2016 and is unsupported

@MrRawes commented on GitHub (Mar 31, 2022): > 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. CORRECTION: yt-dlp does not require an up-to-date python version, the minimum python version is 3.6 first released in late 2016 and is unsupported

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Apr 20, 2022):

just wondering why @dirkf is listed as "Contributor" instead of "Collaborator"

@MrRawes commented on GitHub (Apr 20, 2022): just wondering why @dirkf is listed as "Contributor" instead of "Collaborator"

deekerman commented

Author

Owner

@pukkandan commented on GitHub (Apr 20, 2022):

just wondering why dirkf is listed as "Contributor" instead of "Collaborator"

He seems to have made his membership to https://github.com/ytdl-org private

~~(I assume you mean Member. Afaik, there is no Collaborator label)~~ nvm

@pukkandan commented on GitHub (Apr 20, 2022): > just wondering why dirkf is listed as "Contributor" instead of "Collaborator" He seems to have made his membership to https://github.com/ytdl-org private ~~(I assume you mean `Member`. Afaik, there is no `Collaborator` label)~~ nvm

deekerman commented

Author

Owner

@dirkf commented on GitHub (Apr 20, 2022):

On the project page there's a list of 700+ "Contributors". I assume these are people recognised by GH as having committed to the project.

On the organisation page there's a list of "People", who I assume are the "Members" of the project.

https://www.activestate.com/products/python/python-2-end-of-life-security-updates/

A non-issue (or several of them) when running the yt-dl command-line program. No doubt someone building a server app that embeds yt-dl will want to use a supported Python version where possible, especially for their credit-card processing module.

@dirkf commented on GitHub (Apr 20, 2022): On the project page there's a list of 700+ "Contributors". I assume these are people recognised by GH as having committed to the project. On the organisation page there's a list of "People", who I assume are the "Members" of the project. > https://www.activestate.com/products/python/python-2-end-of-life-security-updates/ A non-issue (or several of them) when running the yt-dl command-line program. No doubt someone building a server app that embeds yt-dl will want to use a supported Python version where possible, especially for their credit-card processing module.

deekerman commented

here is evidense of Collaborator

Author

Owner

@MrRawes commented on GitHub (Apr 25, 2022):

just wondering why dirkf is listed as "Contributor" instead of "Collaborator"

He seems to have made his membership to https://github.com/ytdl-org private

(I assume you mean Member. Afaik, there is no Collaborator label)

@MrRawes commented on GitHub (Apr 25, 2022): > > just wondering why dirkf is listed as "Contributor" instead of "Collaborator" > > He seems to have made his membership to https://github.com/ytdl-org private > > (I assume you mean `Member`. Afaik, there is no `Collaborator` label) [here is evidense of `Collaborator`](https://github.com/ytdl-org/youtube-dl/pull/29303#issuecomment-862698977)

deekerman commented

Author

Owner

@MrRawes commented on GitHub (Apr 26, 2022):

this page is a bit outdated, could this be updated @dirkf

@MrRawes commented on GitHub (Apr 26, 2022): [this page](http://ytdl-org.github.io/youtube-dl/about.html) is a bit outdated, could this be updated @dirkf

deekerman commented

Author

Owner

@hackerb9 commented on GitHub (May 7, 2022):

@dirkf wrote:

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.

I am grateful for the work you've done on youtube-dl. I hesitate to ask, as I do not want you to feel pressured, but I am wondering if the next stable release is going to drop soonish. I understand that the slow download problem was fixed in the development code, but it still exists in the current release (2021.12.17).

Thanks!

@hackerb9 commented on GitHub (May 7, 2022): @dirkf wrote: > 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. I am grateful for the work you've done on youtube-dl. I hesitate to ask, as I do not want you to feel pressured, but I am wondering if the next stable release is going to drop soonish. I understand that the slow download problem was fixed in the development code, but it still exists in the current release (2021.12.17). Thanks!

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 9, 2022):

@dirkf you or another contributor seems to have unmarked 2021.12.17 as a release, now the releases page only has 2021.05.16 as the latest

will there every be a new release at this repo? I know there is never a good time for a release when there are too many bugs and features to implement, but anything is better than the current release. In the meantime could you re-mark that release, thanks

@theofficialgman commented on GitHub (May 9, 2022): @dirkf you or another contributor seems to have unmarked 2021.12.17 as a release, now the releases page only has 2021.05.16 as the latest will there every be a new release at this repo? I know there is never a good time for a release when there are too many bugs and features to implement, but anything is better than the current release. In the meantime could you re-mark that release, thanks

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (May 9, 2022):

@theofficialgman Are you reading the backlog before you comment?

The crux of it: if you're not using python2, DO NOT USE youtube-dl. This is a relatively unmaintained project that can't track upstream changes. Instead use https://github.com/yt-dlp/yt-dlp

See this for more information,

https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1068588128

@EvanCarroll commented on GitHub (May 9, 2022): @theofficialgman Are you reading the backlog before you comment? The crux of it: if you're not using python2, **DO NOT USE youtube-dl**. This is a relatively unmaintained project that can't track upstream changes. Instead use https://github.com/yt-dlp/yt-dlp See this for more information, * https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1068588128

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 9, 2022):

@theofficialgman Are you reading the backlog before you comment?

yes, I have been tracking this issue since the start. I don't need you try reprimand me.
Dirkf has and plans on continue to do maintenance on this repo and the current master branch of youtube-dl is in a much better place, it just needs a release and for releases to not be deleted (like what has just happened today)

@theofficialgman commented on GitHub (May 9, 2022): > @theofficialgman Are you reading the backlog before you comment? yes, I have been tracking this issue since the start. I don't need you try reprimand me. Dirkf has and plans on continue to do maintenance on this repo and the current master branch of youtube-dl is in a much better place, it just needs a release and for releases to not be deleted (like what has just happened today)

deekerman commented

Author

Owner

@pukkandan commented on GitHub (May 9, 2022):

you or another contributor seems to have unmarked 2021.12.17 as a release, now the releases page only has 2021.05.16 as the latest

It's Github acting up. See https://github.com/yt-dlp/yt-dlp/issues/3653. Clicking "https://github.com/ytdl-org/youtube-dl/releases/tag/2021.12.17" => "Edit release" => "Update release" fixes the issue. Or since this has been hapenning multiple times now, just wait for Github to fix it

PS: Note that unlike yt-dlp, youtube-dl's auto-updater is not affected since it uses https://yt-dl.org/update

@pukkandan commented on GitHub (May 9, 2022): > you or another contributor seems to have unmarked 2021.12.17 as a release, now the releases page only has 2021.05.16 as the latest It's Github acting up. See https://github.com/yt-dlp/yt-dlp/issues/3653. Clicking "https://github.com/ytdl-org/youtube-dl/releases/tag/2021.12.17" => "Edit release" => "Update release" fixes the issue. Or since this has been hapenning multiple times now, just wait for Github to fix it PS: Note that unlike yt-dlp, youtube-dl's auto-updater is not affected since it uses https://yt-dl.org/update

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 9, 2022):

@EvanCarroll also I shouldn't have to tell you this... but youtube-dl is still multiple factors of magnitude faster than yt-dlp... seems like even the latest release of yt-dlp hasn't implemented the throttling fix

edit: actually nevermind, both of them have implemented it. it just appears that neither of the implementations works when used inside XDM

@theofficialgman commented on GitHub (May 9, 2022): @EvanCarroll also I shouldn't have to tell you this... but youtube-dl is still multiple factors of magnitude faster than yt-dlp... seems like even the latest release of yt-dlp hasn't implemented the throttling fix edit: actually nevermind, both of them have implemented it. it just appears that neither of the implementations works when used inside XDM

deekerman commented

Author

Owner

@dirkf commented on GitHub (May 9, 2022):

It looks as if XDM just gets the single JSON output which (for yt-dl) would include the unthrottled media links, as long as youtube-dl or youtube-dl.exe (Windows) runs the unthrottling version.

Apparently GH unlisted 2021.06.06 as well as 2021.12.17, even after I fixed the missing 2021.12.17 last month, but they're back now.

@dirkf commented on GitHub (May 9, 2022): It looks as if XDM just gets the single JSON output which (for yt-dl) would include the unthrottled media links, as long as youtube-dl or youtube-dl.exe (Windows) runs the unthrottling version. Apparently GH unlisted 2021.06.06 as well as 2021.12.17, even after I [fixed the missing 2021.12.17](https://github.com/ytdl-org/youtube-dl/issues/30825) last month, but they're back now.

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 9, 2022):

It looks as if XDM just gets the single JSON output which (for yt-dl) would include the unthrottled media links, as long as youtube-dl or youtube-dl.exe (Windows) runs the unthrottling version.

Apparently GH unlisted 2021.06.06 as well as 2021.12.17, even after I fixed the missing 2021.12.17 last month, but they're back now.

I've tried myself downloading from the URLs in the json (-j) and they are indeed slow (they are not when downloading with youtube-dl directly)
are the URLs only valid to download quickly if you start downloading immediately or something? the expire time from the link has not passed (seems to be 6 hours in the future) but the download is still VERY slow if I do something like download with wget

@theofficialgman commented on GitHub (May 9, 2022): > It looks as if XDM just gets the single JSON output which (for yt-dl) would include the unthrottled media links, as long as youtube-dl or youtube-dl.exe (Windows) runs the unthrottling version. > > Apparently GH unlisted 2021.06.06 as well as 2021.12.17, even after I [fixed the missing 2021.12.17](https://github.com/ytdl-org/youtube-dl/issues/30825) last month, but they're back now. I've tried myself downloading from the URLs in the json (-j) and they are indeed slow (they are not when downloading with youtube-dl directly) are the URLs only valid to download quickly if you start downloading immediately or something? the expire time from the link has not passed (seems to be 6 hours in the future) but the download is still VERY slow if I do something like download with `wget`

deekerman commented

Author

Owner

@dirkf commented on GitHub (May 9, 2022):

Shouldn't happen. More likely, XDM is running another yt-dl that you haven't updated.

@dirkf commented on GitHub (May 9, 2022): Shouldn't happen. More likely, XDM is running another yt-dl that you haven't updated.

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 9, 2022):

Shouldn't happen. More likely, XDM is running another yt-dl that you haven't updated.

I'm testing this manually, not through XDM
I run youtube-dl https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq
then pick a URL, and wget it and the download speed is only a few kbps

through youtube-dl (aka: youtube-dl https://www.youtube.com/watch?v=NPBnphbYGFw -f 247) it is full speed

@theofficialgman commented on GitHub (May 9, 2022): > Shouldn't happen. More likely, XDM is running another yt-dl that you haven't updated. I'm testing this manually, not through XDM I run `youtube-dl https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq` then pick a URL, and `wget` it and the download speed is only a few kbps through youtube-dl (aka: `youtube-dl https://www.youtube.com/watch?v=NPBnphbYGFw -f 247`) it is full speed

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (May 10, 2022):

@theofficialgman - What do you mean that both of them have implemented the throttling fix? The last version I'm aware of is 2021.12.17 and that version is super-slow at downloading YouTube videos. In fact, I made a script to get the URLs for videos and then send them to Internet Download Manager so it can use 16 connections to download them. I get a whopping 1MB/s this way.

@Rekrullurker commented on GitHub (May 10, 2022): @theofficialgman - What do you mean that both of them have implemented the throttling fix? The last version I'm aware of is 2021.12.17 and that version is super-slow at downloading YouTube videos. In fact, I made a script to get the URLs for videos and then send them to Internet Download Manager so it can use 16 connections to download them. I get a whopping 1MB/s this way.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (May 10, 2022):

@EvanCarroll also I shouldn't have to tell you this... but youtube-dl is still multiple factors of magnitude faster than yt-dlp... seems like even the latest release of yt-dlp hasn't implemented the throttling fix

edit: actually nevermind, both of them have implemented it. it just appears that neither of the implementations works when used inside XDM

Certainly yt-dlp is working fine. They're both python. They're both from the same code base. But yt-dlp is simply more modern and has an additional 200 contributors. I only mean to say that development work on this fix or bug will most probably not be done here first. So respectfully, you're either encountering another issue, or you need to file a bug on yt-dlp or search their issue backlog. Moreover, it seem if you're trying to report a bug doing so under a tab called "Under new management" is probably not a great idea.

It would be easier to trouble shoot this issue if you wrote the jq to pick the url which doesn't work for you, or if you provided the url.

@EvanCarroll commented on GitHub (May 10, 2022): > @EvanCarroll also I shouldn't have to tell you this... but youtube-dl is still multiple factors of magnitude faster than yt-dlp... seems like even the latest release of yt-dlp hasn't implemented the throttling fix > > edit: actually nevermind, both of them have implemented it. it just appears that neither of the implementations works when used inside XDM Certainly yt-dlp is working fine. They're both python. They're both from the same code base. But yt-dlp is simply more modern and has an **additional 200 contributors.** I only mean to say that development work on this fix or bug will most probably not be done here first. So respectfully, you're either encountering another issue, or you need to file a bug on yt-dlp or search their issue backlog. Moreover, it seem if you're trying to report a bug doing so under a tab called "Under new management" is probably not a great idea. ---- It would be easier to trouble shoot this issue if you wrote the `jq` to pick the url which doesn't work for you, or if you provided the url.

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 10, 2022):

It would be easier to trouble shoot this issue if you wrote the jq to pick the url which doesn't work for you, or if you provided the url.

I can't provide the URL, it expires in 6 hours
you can use any of them, each URL is for a different quality/videoformat that youtube offers. they are all slow to download from when used directly, you can try yourself. jq is just used to visualize the json.

as I said, both youtube-dl and yt-dlp URLs taken directly from the output json do NOT work fast. you have to download directly with the python scripts

@theofficialgman commented on GitHub (May 10, 2022): > It would be easier to trouble shoot this issue if you wrote the `jq` to pick the url which doesn't work for you, or if you provided the url. I can't provide the URL, it expires in 6 hours you can use any of them, each URL is for a different quality/videoformat that youtube offers. they are all slow to download from when used directly, you can try yourself. jq is just used to visualize the json. as I said, both youtube-dl and yt-dlp URLs taken directly from the output json do NOT work fast. you have to download directly with the python scripts

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 10, 2022):

@theofficialgman - What do you mean that both of them have implemented the throttling fix? The last version I'm aware of is 2021.12.17 and that version is super-slow at downloading YouTube videos.

I'm talking the master branch of each project. both have the throttling fix. youtube-dl is not made a release yet including it, necessitating building from source, which is what my original comment was about (see below)

will there every be a new release at this repo? I know there is never a good time for a release when there are too many bugs and features to implement, but anything is better than the current release.

@theofficialgman commented on GitHub (May 10, 2022): > @theofficialgman - What do you mean that both of them have implemented the throttling fix? The last version I'm aware of is 2021.12.17 and that version is super-slow at downloading YouTube videos. I'm talking the master branch of each project. both have the throttling fix. youtube-dl is not made a release yet including it, necessitating building from source, which is what my original comment was about (see below) > will there every be a new release at this repo? I know there is never a good time for a release when there are too many bugs and features to implement, but anything is better than the current release.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (May 10, 2022):

@theofficialgman so just for clarity when you say "I'm talking the master branch of each project. both have the throttling fix. youtube-dl is not made a release yet including it, necessitating building from source, which is what my original comment was about (see below)". There is an implicit ytdl has made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short.

I assume ytdl has made a release, only because I'm downloading very fast when I target those urls in ytdl (and I'm using release).

@EvanCarroll commented on GitHub (May 10, 2022): @theofficialgman so just for clarity when you say _"I'm talking the master branch of each project. both have the throttling fix. youtube-dl is not made a release yet including it, necessitating building from source, which is what my original comment was about (see below)"._ There is an implicit ytdl **has** made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short. I assume ytdl has made a release, only because I'm downloading very fast when I target those urls in ytdl (and I'm using release).

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 10, 2022):

There is an implicit ytdl has made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short.

yt-dlp has made a release, NO it does not solve this problem. the throttling fix in both yt-dlp (master github history and in the latest release) and youtube-dl (master github history, not in the latest release) only works when using the python scripts directly. it does NOT WORK when ouputing the json and curl/wget/download the files from the resulting URLs

again, TRY IT YOURSELF if you don't believe or understand

yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq

pick format id 251 (the last url in the list), downloading with wget is VERY slow
when I ran it a few minutes ago, I got this url

https://rr1---sn-nv0uixgo-5uae.googlevideo.com/videoplayback?expire=1652223017&ei=yZd6YteNIYeL8wTm653gCw&ip=216.96.225.205&id=o-AAWjnrGES96BSWzx-o8lHeliWBeDQpmYYwmDdICXV6sM&itag=251&source=youtube&requiressl=yes&mh=MA&mm=31%2C29&mn=sn-nv0uixgo-5uae%2Csn-5uaezn7e&ms=au%2Crdu&mv=m&mvi=1&pl=18&initcwndbps=1186250&vprv=1&mime=audio%2Fwebm&gir=yes&clen=138970934&dur=8073.401&lmt=1645227972370105&mt=1652201117&fvip=1&keepalive=yes&fexp=24001373%2C24007246&beids=23886203&c=ANDROID&txp=5432434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRQIhAOKhEjX1hrSUfB-WkGwWXfGOVKmmNNXOvWFPs_sRY5RdAiA4nDokSqMoMAzqFT7fmELGvoyiJPVHvQYt4RqC8t0hdA%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgagVyhGdVuuTaZQ3H8jTkgZE-_s4zNPtwpV6takIIUUUCIANaxwqjQLVQiHw0x1s2dfy2i2cnW06UQgaGg_uk781M

yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -f 251

downloading is VERY fast

@theofficialgman commented on GitHub (May 10, 2022): > There is an implicit ytdl **has** made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short. yt-dlp has made a release, NO it does not solve this problem. the throttling fix in both yt-dlp (master github history and in the latest release) and youtube-dl (master github history, not in the latest release) only works when using the python scripts directly. it does NOT WORK when ouputing the json and curl/wget/download the files from the resulting URLs again, TRY IT YOURSELF if you don't believe or understand ``` yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq ``` pick format id 251 (the last url in the list), downloading with wget is VERY slow when I ran it a few minutes ago, I got this url ``` https://rr1---sn-nv0uixgo-5uae.googlevideo.com/videoplayback?expire=1652223017&ei=yZd6YteNIYeL8wTm653gCw&ip=216.96.225.205&id=o-AAWjnrGES96BSWzx-o8lHeliWBeDQpmYYwmDdICXV6sM&itag=251&source=youtube&requiressl=yes&mh=MA&mm=31%2C29&mn=sn-nv0uixgo-5uae%2Csn-5uaezn7e&ms=au%2Crdu&mv=m&mvi=1&pl=18&initcwndbps=1186250&vprv=1&mime=audio%2Fwebm&gir=yes&clen=138970934&dur=8073.401&lmt=1645227972370105&mt=1652201117&fvip=1&keepalive=yes&fexp=24001373%2C24007246&beids=23886203&c=ANDROID&txp=5432434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRQIhAOKhEjX1hrSUfB-WkGwWXfGOVKmmNNXOvWFPs_sRY5RdAiA4nDokSqMoMAzqFT7fmELGvoyiJPVHvQYt4RqC8t0hdA%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgagVyhGdVuuTaZQ3H8jTkgZE-_s4zNPtwpV6takIIUUUCIANaxwqjQLVQiHw0x1s2dfy2i2cnW06UQgaGg_uk781M ``` ``` yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -f 251 ``` downloading is VERY fast

deekerman commented

Author

Owner

@Rekrullurker commented on GitHub (May 10, 2022):

@theofficialgman - Ok, thanks for the explanation. Unfortunately, I don't know how to compile the source myself. I have only ever successfully compiled two programs in my entire life and both times, I had explicit, step-by-step instructions that told me exactly what I needed to download, where to put everything, what program to use and how to set the options.

@Rekrullurker commented on GitHub (May 10, 2022): @theofficialgman - Ok, thanks for the explanation. Unfortunately, I don't know how to compile the source myself. I have only ever successfully compiled two programs in my entire life and both times, I had explicit, step-by-step instructions that told me exactly what I needed to download, where to put everything, what program to use and how to set the options.

deekerman commented

Author

Owner

@garoto commented on GitHub (May 10, 2022):

Is this really the issue where people should inquire and argue about anything other than what the title suggests? Frickin' hell, it's nuts.

@garoto commented on GitHub (May 10, 2022): Is this really the issue where people should inquire and argue about anything other than what the title suggests? Frickin' hell, it's nuts.

deekerman commented

Author

Owner

@coletdjnz commented on GitHub (May 10, 2022):

There is an implicit ytdl has made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short.

yt-dlp has made a release, NO it does not solve this problem. the throttling fix in both yt-dlp (master github history and in the latest release) and youtube-dl (master github history, not in the latest release) only works when using the python scripts directly. it does NOT WORK when ouputing the json and curl/wget/download the files from the resulting URLs

again, TRY IT YOURSELF if you don't believe or understand
yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq
pick format id 251 (the last url in the list), downloading with wget is VERY slow when I ran it a few minutes ago, I got this url
https://rr1---sn-nv0uixgo-5uae.googlevideo.com/videoplayback?expire=1652223017&ei=yZd6YteNIYeL8wTm653gCw&ip=216.96.225.205&id=o-AAWjnrGES96BSWzx-o8lHeliWBeDQpmYYwmDdICXV6sM&itag=251&source=youtube&requiressl=yes&mh=MA&mm=31%2C29&mn=sn-nv0uixgo-5uae%2Csn-5uaezn7e&ms=au%2Crdu&mv=m&mvi=1&pl=18&initcwndbps=1186250&vprv=1&mime=audio%2Fwebm&gir=yes&clen=138970934&dur=8073.401&lmt=1645227972370105&mt=1652201117&fvip=1&keepalive=yes&fexp=24001373%2C24007246&beids=23886203&c=ANDROID&txp=5432434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRQIhAOKhEjX1hrSUfB-WkGwWXfGOVKmmNNXOvWFPs_sRY5RdAiA4nDokSqMoMAzqFT7fmELGvoyiJPVHvQYt4RqC8t0hdA%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgagVyhGdVuuTaZQ3H8jTkgZE-_s4zNPtwpV6takIIUUUCIANaxwqjQLVQiHw0x1s2dfy2i2cnW06UQgaGg_uk781M
yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -f 251
downloading is VERY fast

This is an issue with your process (or whatever external application you are using), and not youtube-dl or yt-dlp.

It sounds to me you are just passing the raw link to wget and expecting to get full speeds. You are probably not setting http chunk size (has been required for many years for youtube to not be throttled) and using the default wget user agent to name a few.

The built-in downloader works fine due to being configured in a way that is optimised for this use.

Also, yeah, open a new issue. This is offtopic.

@coletdjnz commented on GitHub (May 10, 2022): > > There is an implicit ytdl **has** made a release, and using it will solve your problem (unless you're need python2 support)? And thus my original comment about it being more maintained is at least useful ;) even if the tone I'll grant you is a bit ... short. > > yt-dlp has made a release, NO it does not solve this problem. the throttling fix in both yt-dlp (master github history and in the latest release) and youtube-dl (master github history, not in the latest release) only works when using the python scripts directly. it does NOT WORK when ouputing the json and curl/wget/download the files from the resulting URLs > > again, TRY IT YOURSELF if you don't believe or understand > > ``` > yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -qiJ | jq > ``` > > pick format id 251 (the last url in the list), downloading with wget is VERY slow when I ran it a few minutes ago, I got this url > > ``` > https://rr1---sn-nv0uixgo-5uae.googlevideo.com/videoplayback?expire=1652223017&ei=yZd6YteNIYeL8wTm653gCw&ip=216.96.225.205&id=o-AAWjnrGES96BSWzx-o8lHeliWBeDQpmYYwmDdICXV6sM&itag=251&source=youtube&requiressl=yes&mh=MA&mm=31%2C29&mn=sn-nv0uixgo-5uae%2Csn-5uaezn7e&ms=au%2Crdu&mv=m&mvi=1&pl=18&initcwndbps=1186250&vprv=1&mime=audio%2Fwebm&gir=yes&clen=138970934&dur=8073.401&lmt=1645227972370105&mt=1652201117&fvip=1&keepalive=yes&fexp=24001373%2C24007246&beids=23886203&c=ANDROID&txp=5432434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Cmime%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRQIhAOKhEjX1hrSUfB-WkGwWXfGOVKmmNNXOvWFPs_sRY5RdAiA4nDokSqMoMAzqFT7fmELGvoyiJPVHvQYt4RqC8t0hdA%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRAIgagVyhGdVuuTaZQ3H8jTkgZE-_s4zNPtwpV6takIIUUUCIANaxwqjQLVQiHw0x1s2dfy2i2cnW06UQgaGg_uk781M > ``` > > ``` > yt-dlp https://www.youtube.com/watch?v=NPBnphbYGFw -f 251 > ``` > > downloading is VERY fast This is an issue with your process (or whatever external application you are using), and not youtube-dl or yt-dlp. It sounds to me you are just passing the raw link to wget and expecting to get full speeds. You are probably not setting http chunk size (has been required for many years for youtube to not be throttled) and using the default wget user agent to name a few. The built-in downloader works fine due to being configured in a way that is optimised for this use. Also, yeah, open a new issue. This is offtopic.

deekerman commented

Author

Owner

@theofficialgman commented on GitHub (May 10, 2022):

This is an issue with your process (or whatever external application you are using), and not youtube-dl or yt-dlp.

It sounds to me you are just passing the raw link to wget and expecting to get full speeds. You are probably not setting http chunk size (has been required for many years for youtube to not be throttled) and using the default wget user agent to name a few.

The built-in downloader works fine due to being configured in a way that is optimised for this use.

Also, yeah, open a new issue. This is offtopic.

@coletdjnz thank you for this. I was not aware and @dirkf informed me that this was possible (just downloading at full speed from wget directly using the link) https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1121649546

I guess they were confused. Your explanation matches what I would have guessed and explains why wget and downloads through XDM are slow. It might be helpful to add documentation stating this or even define what steps might be necessary to obtain full download speeds with just the link, user agent, http chunk size, and whatever else is necessary

@theofficialgman commented on GitHub (May 10, 2022): > This is an issue with your process (or whatever external application you are using), and not youtube-dl or yt-dlp. > > It sounds to me you are just passing the raw link to wget and expecting to get full speeds. You are probably not setting http chunk size (has been required for many years for youtube to not be throttled) and using the default wget user agent to name a few. > > The built-in downloader works fine due to being configured in a way that is optimised for this use. > > Also, yeah, open a new issue. This is offtopic. @coletdjnz thank you for this. I was not aware and @dirkf informed me that this was possible (just downloading at full speed from wget directly using the link) https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1121649546 I guess they were confused. Your explanation matches what I would have guessed and explains why wget and downloads through XDM are slow. It might be helpful to add documentation stating this or even define what steps might be necessary to obtain full download speeds with just the link, user agent, http chunk size, and whatever else is necessary

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (May 11, 2022):

I can confirm this issue too now. Thanks for working with me.

yt-dlp "https://www.youtube.com/watch?v=NPBnphbYGFw" -qiJ | jq -r '.formats[] | select(.format_id == "251").url' | xargs yt-dlp -v -o out.webm

Vs,

yt-dlp -v "https://www.youtube.com/watch?v=NPBnphbYGFw"

Not sure why these two yt-dlp (no curl required) commands would download the same url differently.

@EvanCarroll commented on GitHub (May 11, 2022): I can confirm this issue too now. Thanks for working with me. ```sh yt-dlp "https://www.youtube.com/watch?v=NPBnphbYGFw" -qiJ | jq -r '.formats[] | select(.format_id == "251").url' | xargs yt-dlp -v -o out.webm ``` Vs, ```sh yt-dlp -v "https://www.youtube.com/watch?v=NPBnphbYGFw" ``` Not sure why these two `yt-dlp` (no curl required) commands would download the same url differently.

deekerman commented

Author

Owner

@coletdjnz commented on GitHub (May 11, 2022):

I can confirm this issue too now. Thanks for working with me.
yt-dlp "https://www.youtube.com/watch?v=NPBnphbYGFw" -qiJ | jq -r '.formats[] | select(.format_id == "251").url' | xargs yt-dlp -v -o out.webm
Vs,
yt-dlp -v "https://www.youtube.com/watch?v=NPBnphbYGFw"
Not sure why these two yt-dlp (no curl required) commands would download the same url differently.

the former isn't passing info about http chunk size to the downloader while the latter is. this is because it is the extractor that sets the value for the downloader to use. you can of course pass this manually with --http-chunk-size

the chunk size for downloader to use is set in the downloader args in formats that are applicable (have a look through the info json and you will see it in some formats)

"downloader_options": {
        "http_chunk_size": 10485760
      },

@coletdjnz commented on GitHub (May 11, 2022): > I can confirm this issue too now. Thanks for working with me. > > ```shell > yt-dlp "https://www.youtube.com/watch?v=NPBnphbYGFw" -qiJ | jq -r '.formats[] | select(.format_id == "251").url' | xargs yt-dlp -v -o out.webm > ``` > > Vs, > > ```shell > yt-dlp -v "https://www.youtube.com/watch?v=NPBnphbYGFw" > ``` > > Not sure why these two `yt-dlp` (no curl required) commands would download the same url differently. the former isn't passing info about http chunk size to the downloader while the latter is. this is because it is the extractor that sets the value for the downloader to use. you can of course pass this manually with `--http-chunk-size` the chunk size for downloader to use is set in the downloader args in formats that are applicable (have a look through the info json and you will see it in some formats) ```json "downloader_options": { "http_chunk_size": 10485760 }, ```

deekerman commented

Author

Owner

@dirkf commented on GitHub (May 13, 2022):

To conclude the OT interlude, it appears that you would need wget2 to specify a chunk size. wget and curl don't seem to have an option that does so. -k ... may work for aria2c.

@dirkf commented on GitHub (May 13, 2022): To conclude the OT interlude, it appears that you would need _wget2_ to specify a chunk size. _wget_ and _curl_ don't seem to have an option that does so. `-k ...` may work for _aria2c_.

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jun 13, 2022):

@dirkf can I suggest creating a fixed-in-dlp tag for issues/PRs in this repo that have been fixed/merged/aren't applicable in yt-dlp? I'm happy to take on the responsibility of finding issues that fit that category and sending a list of them in this issue, whenever I've found a good amount.
So far I've found the following issues: #29624, #30839, #30837 (fixed by adding certifi), #6, #622 (I didn't bother reading through the full conversation of 60+ messages, but based on reading the original message, this would work in yt-dlp using --download-sections), #30822 and #30998

@gamer191 commented on GitHub (Jun 13, 2022): @dirkf can I suggest creating a `fixed-in-dlp` tag for issues/PRs in this repo that have been fixed/merged/aren't applicable in yt-dlp? I'm happy to take on the responsibility of finding issues that fit that category and sending a list of them in this issue, whenever I've found a good amount. So far I've found the following issues: #29624, #30839, #30837 (fixed by adding certifi), #6, #622 (I didn't bother reading through the full conversation of 60+ messages, but based on reading the original message, this would work in yt-dlp using `--download-sections`), #30822 and #30998

deekerman commented

Author

Owner

@dirkf commented on GitHub (Jun 13, 2022):

The freetext issue search works well so just add a comment including fixed_in_dlp (_ isn't a split character for the search).

Looking at the list:

#29624 should be included in a back-port
#30839 should be fixed by someone reconfiguring the templates
#30837 is an OS problem, fixed by installing Linux ;-)
#6 can be addressed with PR #30723
#622 is solved by using ffmpeg with the appropriate --external-downloader-args ... (though possibly improved by being able to specify where in the command the args should be inserted)
#30822 could be addressed by someone making a back-port, or using an external program
#30998 is already a back-port.

@dirkf commented on GitHub (Jun 13, 2022): The freetext issue search works well so just add a comment including `fixed_in_dlp` (`_` isn't a split character for the search). Looking at the list: * #29624 should be included in a back-port * #30839 should be fixed by someone reconfiguring the templates * #30837 is an OS problem, fixed by installing Linux ;-) * #6 can be addressed with PR #30723 * #622 is solved by using _ffmpeg_ with the appropriate `--external-downloader-args ...` (though possibly improved by being able to specify where in the command the args should be inserted) * #30822 could be addressed by someone making a back-port, or using an external program * #30998 is already a back-port.

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jun 13, 2022):

#29624 is a PR, which should just be merged imo, given how simple it is.
Actually, on 2nd thought, there's probably a better way of doing it, which won't involve a new commit every time a higher quality gets added to ABC iview, given, based on my limited python knowledge, it appears that all that that part of the code is doing is selecting all the options under the hls header in the show's json file (example). But given that it's not the end of the world to create a new commit once every few years, and this project has enough issues already, I reckon #29624 should just get merged.

Moving on, #30839 gets fixed by switching from the old issue templates to the new issue forms (if you've never used an issue form before, you can begin creating a new issue on yt-dlp's repo in order to see what they're like. But obviously don't submit the issue report😉)

#30837 could be fixed by installing Linux, but Linux's hardware compatibility is almost as shit as Australia's last prime minister.

https://github.com/ytdl-org/youtube-dl/issues/622 is solved by using ffmpeg with the appropriate --external-downloader-args ... (though possibly improved by being able to specify where in the command the args should be inserted)

um yeah, but a --download-sections option makes it much easier for the end user. I guess this program isn't designed for end users though, it's designed for server admins who's server can't update to python 3.6. So it's fine to not be super user friendly, in my opinion (but #30613 should definitely be dealt with ASAP)

@gamer191 commented on GitHub (Jun 13, 2022): #29624 is a PR, which should just be merged imo, given how simple it is. Actually, on 2nd thought, there's probably a better way of doing it, which won't involve a new commit every time a higher quality gets added to ABC iview, given, based on my limited python knowledge, it appears that all that that part of the code is doing is selecting all the options under the hls header in the show's json file ([example](https://iview.abc.net.au/api/programs/four-corners/NC2203H018S00)). But given that it's not the end of the world to create a new commit once every few years, and this project has enough issues already, I reckon #29624 should just get merged. Moving on, #30839 gets fixed by switching from the old issue templates to the new issue forms (if you've never used an issue form before, you can begin creating a new issue on yt-dlp's repo in order to see what they're like. But obviously don't submit the issue report😉) #30837 could be fixed by installing Linux, but Linux's hardware compatibility is almost as shit as Australia's last prime minister. > https://github.com/ytdl-org/youtube-dl/issues/622 is solved by using ffmpeg with the appropriate `--external-downloader-args ...` (though possibly improved by being able to specify where in the command the args should be inserted) um yeah, but a `--download-sections` option makes it much easier for the end user. I guess this program isn't designed for end users though, it's designed for server admins who's server can't update to `python 3.6`. So it's fine to not be super user friendly, in my opinion (but #30613 should definitely be dealt with ASAP)

deekerman commented

Author

Owner

@gamer191 commented on GitHub (Jun 16, 2022):

sorry, I forgot about mentioned this issue notifications

@gamer191 commented on GitHub (Jun 16, 2022): sorry, I forgot about `mentioned this issue` notifications

deekerman commented

Author

Owner

@noahbroyles commented on GitHub (Jul 7, 2022):

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.

So is the only point of even keeping this project alive to support hella old versions of Python? Is any new functionality gonna be added? I'd love to see a few issues be closed on this that would actually improve the project. This is the OG of yt-dlp, after all. Let's not let the clone become better than the OG.

@noahbroyles commented on GitHub (Jul 7, 2022): > Just your standard [Internet hound](https://i.kym-cdn.com/photos/images/original/000/427/569/bfa.jpg). > > 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. So is the only point of even keeping this project alive to support hella old versions of Python? Is any new _functionality_ gonna be added? I'd love to see a few issues be closed on this that would actually improve the project. This is the OG of yt-dlp, after all. Let's not let the clone become better than the OG.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Jul 7, 2022):

This is the OG of yt-dlp, after all. Let's not let the clone become better than the OG.

If you could think of any way to quantify what would signify the point in which "the clone" became better, you'd have already realize that point is at least 3 years in the past. Welcome.

@EvanCarroll commented on GitHub (Jul 7, 2022): > This is the OG of yt-dlp, after all. Let's not let the clone become better than the OG. If you could think of any way to quantify what would signify the point in which "the clone" became better, you'd have already realize that point is **at least** 3 years in the past. Welcome.

deekerman commented

Author

Owner

@noahbroyles commented on GitHub (Jul 8, 2022):

If you could think of any way to quantify what would signify the point in which "the clone" became better, you'd have already realize that point is at least 3 years in the past. Welcome.

@EvanCarroll yeah, I stopped using youtube-dl and switched to yt-dlp because of the damn n descramble blowup. What I meant to say is, we have some catching up to do.

@noahbroyles commented on GitHub (Jul 8, 2022): > If you could think of any way to quantify what would signify the point in which "the clone" became better, you'd have already realize that point is **at least** 3 years in the past. Welcome. @EvanCarroll yeah, I stopped using `youtube-dl` and switched to `yt-dlp` because of the damn [`n` descramble blowup](https://github.com/ytdl-org/youtube-dl/pull/30184). What I meant to say is, we have some catching up to do.

deekerman commented

Author

Owner

@Tachi107 commented on GitHub (Sep 20, 2022):

C is 50 years old, and the device you're reading this on relies on it for all of its basic functionalities... I'm pretty sure that youtube-dl can continue to be developed while targeting Python 2.6 :)

@Tachi107 commented on GitHub (Sep 20, 2022): C is 50 years old, and the device you're reading this on relies on it for all of its basic functionalities... I'm pretty sure that youtube-dl can continue to be developed while targeting Python 2.6 :)

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Sep 20, 2022):

@Tachi107 That's silly. You're arbitrarily looking at the first-release date, which has no relevance to the conversation.

C - the language - is still being maintained (ie C17)
C - the compilers - are still being maintained GCC / Clang, in the open source world. New versions come out quite frequently.
C - standard libraries are maintained - MUSL, libc, etc.

None of this is true for Python2. It's dead.

@EvanCarroll commented on GitHub (Sep 20, 2022): @Tachi107 That's silly. You're arbitrarily looking at the first-release date, which has no relevance to the conversation. * C - the language - is still being maintained (ie [C17](https://en.wikipedia.org/wiki/C17_(C_standard_revision))) * C - the compilers - are still being maintained [GCC](https://en.wikipedia.org/wiki/GNU_Compiler_Collection) / [Clang](https://en.wikipedia.org/wiki/Clang), in the open source world. New versions come out quite frequently. * C - standard libraries are maintained - [MUSL](https://en.wikipedia.org/wiki/Musl), [libc](https://en.wikipedia.org/wiki/C_standard_library), etc. None of this is true for Python2. It's dead.

deekerman commented

Author

Owner

@Tachi107 commented on GitHub (Sep 20, 2022):

You're arbitrarily looking at the first-release date, which has no relevance to the conversation.

That's fair, but it is also true that new C versions are not widely available (MSVC does not even completely support C11...). And in any case, projects like curl still use C89, because regardless of what the language is doing, if you want to stay highly portable you have to stick to outdated stuff, see the next point.

None of this is true for Python2. It's dead.

Who cares. If it has users, you have to respect the project's decision to continue supporting it. Believe it or not, some platforms are still stuck with Python2 (like NonStop OS on ia64), and do not have any Python3 port. Yeah, you and I probably don't need to worry about this, but somebody else might do :)

Edit: please, don't go to the OpenSSL thread to ask things unrelated to their issue, you'll notify all the people subscribed to that thread.

@Tachi107 commented on GitHub (Sep 20, 2022): > You're arbitrarily looking at the first-release date, which has no relevance to the conversation. That's fair, but it is also true that new C versions are not widely available (MSVC does not even completely support C11...). And in any case, projects like curl [still use C89](https://github.com/curl/curl/blob/c616259bd1a94fd6b0a39ace9f68a3616f77383c/docs/FAQ#L1512), because regardless of what the language is doing, if you want to stay highly portable you have to stick to outdated stuff, see the next point. > None of this is true for Python2. It's dead. Who cares. If it has users, you have to respect the project's decision to continue supporting it. Believe it or not, some platforms are still stuck with Python2 (like NonStop OS on ia64), and do not have any Python3 port. Yeah, _you and I_ probably don't need to worry about this, but somebody else might do :) Edit: please, don't go to the OpenSSL thread to ask things unrelated to their issue, you'll notify all the people subscribed to that thread.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Sep 20, 2022):

It doesn't have users, and you're just wrong on those points. =)

What MSVC does is of no consequence., but it does support C11, and C17:
- https://learn.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170
- https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/
C11/C17 is highly portable, regardless of what MSVC does. There is a C17 compiler for like every platform produced: https://gcc.gnu.org/install/specific.html
Curl doesn't use C89, for portability. They use it because that's what they did in the 90s. Most C programs have since at least updated to C99. From the FAQ,

We started out using C89 in the 1990s because that was the only way to write a truly portable C program and have it run as widely as possible. C89 was for a long time even necessary to make things work on otherwise considered modern platforms such as Windows. Today, we do not really know how many users that still require the use of a C89 compiler.

I can't see "we do not really know how many users that still require the use" substantiating the claim that they need to use C89 for portability. But reminder, C89is still a supported language unlike Python2. You can still compile programs in every modern C compiler using the C89 standard. And there is still a support ecosystem and toolchain to ensure your code is valid C89. That is to say, it's and secure and maintained this is just a rehash of your prior argument about looking at "arbitrarily looking at the first-release date".

Who cares. If it has users, [...] "continue supporting it"

It doesn't, and if did they're running insecure code. But if there were users and if Python 2 was supported upstream, I would agree.

@EvanCarroll commented on GitHub (Sep 20, 2022): It doesn't have users, and you're just wrong on those points. =) * What MSVC does is of no consequence., but it does support C11, and C17: * https://learn.microsoft.com/en-us/cpp/overview/install-c17-support?view=msvc-170 * https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/ * C11/C17 is highly portable, regardless of what MSVC does. There is a C17 compiler for like every platform produced: https://gcc.gnu.org/install/specific.html * Curl doesn't use C89, for portability. They use it because that's what they did in the 90s. Most C programs have since _at least_ updated to C99. From the FAQ, > We started out using C89 in the 1990s because that was the only way to write a truly portable C program and have it run as widely as possible. C89 was for a long time even necessary to make things work on otherwise considered modern platforms such as Windows. **Today, we do not really know how many users that still require the use of a C89 compiler.** I can't see "we do not really know how many users that still require the use" substantiating the claim that they need to use C89 for portability. But reminder, C89is still a supported language unlike Python2. You can still compile programs in every modern C compiler using the C89 standard. And there is still a support ecosystem and toolchain to ensure your code is valid C89. That is to say, it's and secure and maintained this is just a rehash of your prior argument about looking at "arbitrarily looking at the first-release date". > Who cares. If it has users, [...] "continue supporting it" It doesn't, and if did they're running insecure code. But if there were users and if Python 2 was supported upstream, I would agree.

deekerman commented

Author

Owner

@Tachi107 commented on GitHub (Sep 20, 2022):

This thread is not about C (but you're free to try to use C11 threads on Windows, regardless of which compiler you use - it is not going to work).

Who cares. If it has users, [...] "continue supporting it"

It doesn't, and if did they're running insecure code. But if there were users and if Python 2 was supported upstream, I would agree.

Security is not that relevant in all contexts (and is overlooked when it really matters), and, as already mentioned in this thread, there're plenty of embedded (and not) systems running a fixed release of python; my local train station still uses Debian 6 or something, for instance.

Anyway, you're free to think and use whatever you want - just stop being so ungrateful towards people developing software you use for free.

@Tachi107 commented on GitHub (Sep 20, 2022): This thread is not about C (but you're free to try to use [C11 threads](https://en.cppreference.com/w/c/thread) on Windows, regardless of which compiler you use - it is not going to work). > > Who cares. If it has users, [...] "continue supporting it" > > It doesn't, and if did they're running insecure code. But if there were users and if Python 2 was supported upstream, I would agree. Security is not that relevant in all contexts (and is overlooked when it really matters), and, as already mentioned in this thread, there're plenty of embedded (and not) systems running a fixed release of python; my local train station still uses Debian 6 or something, for instance. Anyway, you're free to think and use whatever you want - just stop being so ungrateful towards people developing software you use for free.

deekerman commented

Author

Owner

@dirkf commented on GitHub (Sep 20, 2022):

Indeed, https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025018207 (there are other cases).

I'm quite sure the users of the STB application would rather use "insecure code" to access YT and BBC catch-up content that the STB used to support than not be able to do so at all. Equally, they aren't going to be upgrading from Linux kernel 2.6. A Python 2.7 system will still run correct and diagnose incorrect Python 2.7 programs regardless of the support status designated by PSF.

The linked OpenSSL thread is interesting in that **** build tool dependencies as discussed there are exactly why no Py3 exists on the STB platform (sizing might also be a problem, but was never reached).

@dirkf commented on GitHub (Sep 20, 2022): Indeed, https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025018207 (there are other cases). I'm quite sure the users of the STB application would rather use "insecure code" to access YT and BBC catch-up content that the STB used to support than not be able to do so at all. Equally, they aren't going to be upgrading from Linux kernel 2.6. A Python 2.7 system will still run correct and diagnose incorrect Python 2.7 programs regardless of the support status designated by PSF. The linked OpenSSL thread is interesting in that **** build tool dependencies as discussed there are exactly why no Py3 exists on the STB platform (sizing might also be a problem, but was never reached).

deekerman commented

Author

Owner

@scrutinizer11 commented on GitHub (Jan 27, 2023):

It's not like deprecated software suddendly stops working.

Oh really? Then this optimistic statement, somehow, didn't hold, colliding with my experience when after installing the newest Python 3 package, an app stopped working, to my surprise. The trade-in was not a new horizon full of brilliant user experience but the Python launcher, popping up every time I started the app. I don't have the knowledge or time to work out a viable solution for detecting the Py version a given app relies upon, but if I did, would there be a way to tell apps to use different Py?

Some vendors (like Apple, in my case) stick to the hold-out strategy of updating underlining components of their products, such as Python packages. macOS still has bash version 3, which used to be the default. I don't feel the urgency to lay my hands on bash 4. Most users aren't developers, and if they make use of these languages, it usually covers all use cases.
For the same reason, Microsoft kept maintaining Windows 7, speaking of which there's still a significant chunk of the users.
Many people use older hardware not supported by the newest releases, being cut off from updates.

if anyone still needs Python 2.7 support it's either their fault or their problem to deal with

Thank you. You seem to be an empathic type.

and certainly not a good reason to stifle the projects' growth, creating confusion and splitting manpower across 2 projects doing basically the same thing.

What project's growth? As I observe, yt-dlp gets regular updates that, thanks to the developers, I can enjoy on my macOS 10.9 with the stock Python 2, so some backporting magic works. I didn't notice that Py 3 users were hurt.

@scrutinizer11 commented on GitHub (Jan 27, 2023): > It's not like deprecated software suddendly stops working. Oh really? Then this optimistic statement, somehow, didn't hold, colliding with my experience when after installing the newest Python 3 package, an app stopped working, to my surprise. The trade-in was not a new horizon full of brilliant user experience but the Python launcher, popping up every time I started the app. I don't have the knowledge or time to work out a viable solution for detecting the Py version a given app relies upon, but if I did, would there be a way to tell apps to use different Py? Some vendors (like Apple, in my case) stick to the hold-out strategy of updating underlining components of their products, such as Python packages. macOS still has **bash** version 3, which used to be the default. I don't feel the urgency to lay my hands on bash 4. Most users aren't developers, and if they make use of these languages, it usually covers all use cases. For the same reason, Microsoft kept maintaining Windows 7, speaking of which there's still a significant chunk of the users. Many people use older hardware not supported by the newest releases, being cut off from updates. > if anyone still needs Python 2.7 support it's either their fault or their problem to deal with Thank you. You seem to be an empathic type. > and certainly not a good reason to stifle the projects' growth, creating confusion and splitting manpower across 2 projects doing basically the same thing. What project's growth? As I observe, yt-dlp gets regular updates that, thanks to the developers, I can enjoy on my macOS 10.9 with the stock Python 2, so some backporting magic works. I didn't notice that **Py 3** users were hurt.

deekerman commented

Author

Owner

@a-pav commented on GitHub (Mar 14, 2023):

I wish you could just merge the two projects, I think that would have been for the best.

But at least both projects should look alive and have regular releases in order to not lose community focus. I personally don't care for the new shiny features of yt-dlp. I prefer to use the good old widely known youtube-dl but that is getting harder and harder, considering the recent failures (due to changes on the youtube side). It seems that most of the new contributions are happening on yt-dlp, while most new users/adapters are, most probably, searching for youtube-dl and disregard anything else. Beside that it also seems that most of the contributors don't share the vision of the leads here in regards of keeping support for Python 2 and are already moving (moved) away.

I haven't seen anyone asking you to keep supporting Python 2 but I see people asking for a new youtube-dl release left and right.

@a-pav commented on GitHub (Mar 14, 2023): I wish you could just merge the two projects, I think that would have been for the **best**. But at least both projects should look alive and have regular releases in order to not lose community focus. I personally don't care for the new shiny features of yt-dlp. I prefer to use the good old widely known `youtube-dl` but that is getting harder and harder, considering the recent failures (due to changes on the youtube side). It seems that most of the new contributions are happening on yt-dlp, while most new users/adapters are, most probably, searching for `youtube-dl` and disregard anything else. Beside that it also seems that most of the contributors don't share the vision of the leads here in regards of keeping support for Python 2 and are already moving (moved) away. I haven't seen anyone asking you to keep supporting Python 2 but I see people asking for a new `youtube-dl` release left and right.

deekerman commented

Author

Owner

@the-r3dacted commented on GitHub (Apr 4, 2023):

So many fucking people complaining about a good thing. More support means more users. A basic fucking video downloader should work on a toaster, not require the latest """""""""secure""""""""" version of x software that has years of extra bloat and tells you to fuck off if your system is barely out of date.

@the-r3dacted commented on GitHub (Apr 4, 2023): So many fucking people complaining about a good thing. More support means more users. A basic fucking video downloader should work on a toaster, not require the latest """""""""secure""""""""" version of x software that has years of extra bloat and tells you to fuck off if your system is barely out of date.

deekerman commented

Author

Owner

@EvanCarroll commented on GitHub (Apr 4, 2023):

@K4sum1 yt-dlp works on python3.7+, hardly new. It was released in 2018. It's the oldest still supported version of Python 3.

@EvanCarroll commented on GitHub (Apr 4, 2023): @K4sum1 yt-dlp works on python3.7+, hardly new. It was released in 2018. It's the oldest still supported version of Python 3.

deekerman commented

Author

Owner

@Twangist commented on GitHub (Apr 4, 2023):

So is the only point of even keeping this project alive to support hella old versions of Python?

Evidently yes. It seems pathetic that the new bosses would choose that sword to suicide the project on, but that's their (very bad and stupid) choice.

@Twangist commented on GitHub (Apr 4, 2023): > So is the only point of even keeping this project alive to support hella old versions of Python? Evidently yes. It seems pathetic that the new bosses would choose that sword to suicide the project on, but that's their (very bad and stupid) choice.

deekerman commented