youtube-dl
youtube-dl copied to clipboard
ytdl-org
Under new management
Thanks to @rg3 who created this program the project has a new maintainer.
Also, many thanks to @dstftw and @remitamine for holding the fort over the last several years.
I hope that we'll be able to make a new release soon and subsequently keep the program more up-to-date than has been the case for the last few months.
The project has a fork https://github.com/yt-dlp/yt-dlp that offers a lot of extra functions but demands an up-to-date Python version. This project will continue to target Python version 2.6, 2.7, or 3.2+, at least until no-one complains about 2.6 compatibility.
PRs are very welcome, although there is a significant back-log to be handled. Back-ports of yt-dlp features are also welcome.
Finally, I'd encourage anyone else who is interested in sharing maintenance duties to establish a track record and make themselves known. We want to keep this popular project alive with a community of future maintainers.
Supporting defunct versions of Python seems like a great way to handicap the project and a total waste of time.
This repository should just become yt-dlp tbh
By now, yt-dlp has accumulated various incompatibilities with youtube-dl and it is no longer a drop-in replacement for many users. So youtube-dl can't just "become yt-dlp". Since I do not intend to revert these changes, it is best that both projects co-exist.
If you like to use yt-dlp, use it. And if you prefer youtube-dl, use this. It is a waste of everyone's time to post issues/comments asking for either project to "become" the other
fyi python 2 reached EOL 2 years ago, before windows 7 did.
https://www.python.org/doc/sunset-python-2/
This repository should just become yt-dlp tbh
By now, yt-dlp has accumulated various incompatibilities with youtube-dl and it is no longer a drop-in replacement for many users. So youtube-dl can't just "become yt-dlp". Since I do not intend to revert these changes, it is best that both projects co-exist.
If you like to use yt-dlp, use it. And if you prefer youtube-dl, use this. It is a waste of everyone's time to post issues/comments asking for either project to "become" the other
fair enough! Consider mentioning dlp in the readme though?
@Twangist and supporters, please direct your Python 3.7+ enthusiasm to the yt-dlp project, as @pukkandan says.
No-one would bother maintaining two versions of a program if there wasn't a good reason. There are still applications where older Python versions have to be supported: among the known cases are those where that's all the platform offers, and where yt-dl is being embedded in a larger chunk of Python 2 code that no-one is going to port.
This project has already established a compatibility library that largely allows you to code for Python 3 while remaining compatible with Python 2, by using the library's compat_xxx types and avoiding novel syntax elements (nonlocal, yield from, etc), for which there are known work-arounds. With this infrastructure, and provided that yt-dl and yt-dlp continue to support the same extractor API and library functions we can avoid wasted effort on either side.
The project Readme should definitely be updated, in due course, as @boehs suggests.
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 ?
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.
Appreciate the openness, @dirkf. I personally wasn't aware that one of youtube-dl's goals was Python 2 compatibility so thanks for clearing that up for us.
I am not and will not ever advocate for projects closely mirroring each other. But, in case that's a useful user feedback for you: my main reason for moving to yt-dlp was (a) SponsorBlock API support and (b) external downloaders. If these sound like an interesting thing to support for you then I believe others would love to see them implemented as well. If not, the project is still super valuable in its own right.
Thanks for the update. It's appreciated.
Wouldn't it be better to either release an LTS or to set a date when support for everything below 3.6 is dropped.
Motivating people to stay on EOL versions of Python carries a lot of security risks, not just for this project but also for projects that depend on it.
And I would assume that older projects would most likely already have their dependencies version locked anyways.
Python 2 is end of life and no longer receiving any security updates, you supporting Python 2 will just motivate others to not move on from insecure unmaintained dependencies.
You'll also be splitting up manpower by not just encouraging use of yt-dlp, which will affect everyone, not just those who insist on not realizing the past is the past.
You'll also be splitting up manpower by not just encouraging use of yt-dlp, which will affect everyone, not just those who insist on not realizing the past is the past.
To be fair, yt-dlp usually implements all of youtube-dl's commits pretty quickly (unless they conflict with yt-dlp), so youtube-dl continuing to be maintained won't negatively affect yt-dlp that much. Also, https://github.com/ytdl-org/youtube-dl/issues/30568#issuecomment-1025012255 said that youtube-dl's readme will be updated to mention yt-dlp
Just your standard Internet hound.
Just to confirm, Python 2 (or 2 and < 3.6) compatibility wasn't originally a goal of the project since Python 3 appeared only after the project was created, but that level of compatibility is a goal now, since yt-dlp exists for more recent Python versions. And anyone who can practically do so should run a supported Python version, on which yt-dl should run equally well.
The project Readme should definitely be updated, in due course, as boehs suggests.
May I suggest going one step further and informing the user about yt-dlp every time they run youtube-dl --update, if youtube-dl detects that it's running on python 3.6 or above. The user would have to also be informed about the slight differences between youtube-dl and yt-dlp, and that if they update they need to move their config file. Obviously this would be controversial and have downsides, one of which is that it may result in yt-dlp users accidentally reporting issues on the youtube-dl repository.
EDIT: Sorry boehs for the ping, it was an accident
I'd suggest you to unpin (or move to the lowest) #27013 because its title is a bit confusing.
Anyway, I'd appreciate youtube-dl now have a new maintainer.
@gamer191 wrote:
May I suggest going one step further and informing the user about yt-dlp every time they run youtube-dl --update,...
You can suggest it, but I think just updating the documentation will be quite enough. Feel free to try your luck with a PR, though, but I don't fancy your chances.
@Lesmiscore wrote:
I'd suggest you to unpin (or move to the lowest) #27013 because its title is a bit confusing.
Good point, it's not exactly news now, and I hope it won't be again.
Stubbornly supporting products that are way past their due date is absurd. Stop poking at dead bodies and embrace change rather than avoid it at all cost.
Do what the CPython team did: grow some balls, deprecate and move on. People will be angry, it always happens. But enough people are angry now with this project supporting a Python release that is 12 years old.
It's not like deprecated software suddendly stops working. It just isn't maintained anymore: if anyone still needs Python 2.7 support it's either their fault or their problem to deal with and certainly not a good reason to stifle the projects' growth, creating confusion and splitting manpower across 2 projects doing basically the same thing
You can suggest it, but I think just updating the documentation will be quite enough. Feel free to try your luck with a PR, though, but I don't fancy your chances.
Nah, I don't have enough coding skills to do that. If anyone with more skills likes my idea though they're welcome to PR it, but it only received 4 "likes", so I agree that it probably won't be merged in
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
See https://github.com/ytdl-org for details of the yt-dl organisation and its current members.
"This organization has no public members. You must be a member to see who’s a part of this organization."
Not enlightening.
CC @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.
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
I was about to say that earlier.
I personally couldn't care less if you want to use Python 2.6, PHP 4.1 or Perl 5.0. I care whether the project is in the hands of people who believe in its original mission.
@dirkf Pretty sure a lot of people will be watching for some, a-hem, creatively named "experience-improving telemetry" PRs, if you catch my drift.
While many of you are debating the merits of python2 I see none yet questioning who the "new management" are; where they are; who now has access to the repo, etc.
I was about to say that earlier.
I personally couldn't care less if you want to use Python 2.6, PHP 4.1 or Perl 5.0. I care whether the project is in the hands of people who believe in its original mission.
@dirkf Pretty sure a lot of people will be watching for some, a-hem, creatively named "experience-improving telemetry" PRs, if you catch my drift.
What does telemetry have to do with any of this? People here are talking about supporting an EOL platform and you want to randomly involve telemetry with it? wtf.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads. Typical antagonizing behavior from fiery FOSS zealots with too much time on their hands.
I'm willing to bet money none of these people on this issue bitching about the new maintainer credentials or whatnot, can name a single past constant contributor (dstftw doesn't count) from the top of their heads.
I remember the creator has mentioned some past maintainers in their blog, so the organization member should be something like:
So I don't think I'm giving anything away by listing the 6 members as myself (https://github.com//dirkf), the previous two active maintainers (https://github.com//dstftw and https://github.com//remitamine), two of the active maintainers before them (https://github.com//phihag and https://github.com//FiloSottile), and the project creator (https://github.com//rg3).
