Under new management

[dirkf]

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.

[Twangist]

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

[boehs]

This repository should just become yt-dlp tbh

[VixieTSQ]

this is ridiculous. Python 2 is dead

[pukkandan]

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

[ligix]

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

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

[boehs]

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?

[dirkf]

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

[chrizilla]

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 ?

[dirkf]

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.

[dimitarvp]

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.

[spectrapulse]

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.

[Evernow]

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.

[gamer191]

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

[Earnestly]

Who is @dirkf?

[dirkf]

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.

[gamer191]

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

[Lesmiscore]

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.

[dirkf]

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

[nocturn9x]

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

[gamer191]

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

[Earnestly]

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.

[dirkf]

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

[dimitarvp]

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

Not enlightening.

[gamer191]

CC @dirkf

[dirkf]

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.

[dimitarvp]

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.

[spectrapulse]

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.

[garoto]

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.

[kidonng]

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

[dirkf]

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

[Lesmiscore]

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

[dirkf]

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.

[jxu]

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!

[rautamiekka]

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

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

[nocturn9x]

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

[jxu]

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.

[dirkf]

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

[pukkandan]

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

[philcerf]

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?

[jxu]

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.

[dirkf]

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

[nocturn9x]

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

[dirkf]

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

[nocturn9x]

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

[jxu]

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

[nocturn9x]

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

[jxu]

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

[Evernow]

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

[jxu]

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

[dirkf]

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.