YouTube-DL Forks to Continue Supporting Older Versions of Python (github.com) 62
Wikipedia defines youtube-dl as "a free and open source download manager for video and audio from YouTube and over 1,000 other video hosting websites." It was created in 2006, and "According to libraries.io, 308 other packages and 1.43k repositories depend on it." The project now has over 106,000 stars on GitHub, and by one calculation it's their fourth-most starred project that's written in Python.
A new issue today describes the project as "Under new management."
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 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.
Pull Requests 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.
A new issue today describes the project as "Under new management."
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 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.
Pull Requests 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.
You're Not Wrong (Score:2)
Re:You're Not Wrong (Score:5, Insightful)
It seems reasonable to download a movie that is available freely online so you can watch it later.
Re: (Score:2)
Just like it seems pretty reasonable to download a Slackware ISO from a torrent link. Much faster as well. Just don't forget to check signatures and/or at least checksums.
Re: (Score:2)
Also, you don't have to upload when torrenting.
Re: (Score:2)
The offence in torrenting is uploading illegally, with yt-dlp your are downloading legally. Youtube and other sites could easily prevent direct downloading if it was a huge issue for them.
Re:You're Not Wrong (Score:4, Insightful)
No they couldn't. You have to download it in order to play it on your computer. As long as a downloader can pretend to be a browser streaming the content, it can download the content.
Re: (Score:3, Insightful)
Re: (Score:2)
Wow, somebody must have too many sock puppets if this ^ comment is at 0!
It's pretty obviously the Top Shelf Argument for slashdot users; it is a browser. Like, "duh."
Re:You're Not Wrong (Score:4, Insightful)
yt-dlp doesn't suffer from the throttling problems of Youtube-dl.
Re: (Score:2)
Mmm, eventually I was dragged into yt-dlp because all my other programs already hooked with it. All the more power to youtube-dl, but....
I switched because it still works full speed, and youtube-dl falls into the super-slow-lane.
Re: (Score:2)
I thought youtube-dl used to be pretty fast until just a few months ago. Has it always been slow?
Re: (Score:1)
youtube-dl used to rock. Now it'll download stuff eventually. I had stuff where the estimate was 1.5 days. Reminded me of the telephone line days. With yt-dlp it was down in about 8 minutes. I switched to yt-dlp and haven't looked back.
Re: (Score:2)
I installed it a couple years ago and it was really fast, full speed. Then YT changed their algorithm so if you weren't logged in, it would be slow. But you could use your login cookie from the browser and it would still be fast. Then YT changed something more, maybe 6 months ago, and it became slow all the time.
A whole bunch of different forks were made, that changed whatever YT was detecting, and were full speed. yt-dlp is the most popular of these forks.
Basically, the original is not actively developed,
Why? (Score:2)
Python 2 is no longer supported by the primary copyright owners, and has not been supported for more than 2 years. Is there any excuse left not to migrate to python 3 for simple compatibility reasons?
Re: (Score:3)
What is the point of breaking backwards compatibility? That seems to go against the unix mentality.
Re: Why? (Score:2)
What is the point of wasting time and effort supporting two versions of Python?
Re:Why? (Score:5, Insightful)
What is the point of breaking backwards compatibility?
If you remain backwards compatible you can't always use the new features of a language. Some of those might be important for improving security, for example (think of changing from zero terminated. There's a whole load of history which shows that software which ignores and doesn't use the new features gets more and more badly maintained.
The really correct way to do this is to move your software to the new version of the language and then have others write compatibility code which allows the old version of the language to support the new code.
At some point, there aren't enough people interested in doing the work for it to continue reliably. At that point it may be better to tell the people using the old version that, if they aren't willing to take on the backwards compatibility work, the software will no longer be updated.
Re: (Score:2)
The "correct way" was to do such steps 8 years ago, when python 3 had been out for 5 years and stabilized. Continuing to support the deprecated and now entirely obsolete and author unsupported python 2 releases is wasting people's time on what _can_ be done, rather than what _should_ be done.
Re: (Score:2)
That may be a cherished sentiment in parts of the 'Unix' mentality (also, frankly, the Microsoft mentality), but not so much in the python ecosystem. To support python 2.6 through current requires some effort and a lot of dependencies aren't going to do it.
2.7 at least has more 3.x compatible syntax, though you still have a lot of mess to even stick to the 2.7/3.x subset of syntax, and have to manage different core module names and function names, whether you do it manually or by way of six to abstract it
Re: (Score:2)
What is the point of breaking backwards compatibility? That seems to go against the unix mentality.
Sometimes it's the "best bad choice" out of a set of other possible bad choices.
Like having to choose between hacking off a finger or an arm...no good choices there, but one is definitely a better choice than the other.
Re:Why? (Score:4, Insightful)
Any excuse to migrate away from Python 2 is an excuse to migrate away from Python altogether.
Re: (Score:2)
Re: (Score:3)
I suppose the parent means that if they can break compatibility for Python 2, what guarantee do you have they will not dump again all your hard work when they break compatibility for Python 3?
Re: (Score:3)
I suspect phantomfive dislikes python altogether.And significant migrations away from particular releases is a good opportunity to review the devotion to a particular language or toolkit. That was precisely what happened with CentOS last year, as it has become the testing ground for unpredictable RHEL changes rather than a rebuild of corporate tested RHEL. Many are abandoning RHEL based operating systems in favor of Ubuntu, especially if they've decided they prefer Ubuntu's shorter release cycles.
Re: (Score:2)
Indeed, however I strongly favor stable platforms. Python is tolerable, but I'm allergic to breaking changes.
Re: (Score:2)
what guarantee do you have they will not dump again all your hard work when they break compatibility for Python 3?
That's a fair point.
Re: (Score:2)
If I travel Back in time, what vaccines should ... (Score:2)
... I get?
answering to phantomfive's sig...
If you are talking about vaccines in general, I'd say: All of them (at least tht's what I do).
Yellow Fever, meningococo, phneumococo, Tuberculosis, leprosy (yes, there is a vaccine against leprosy), mumps, hep-a, hep-b, common cold/flu, tetanus, polio, mumps, melasses, HPV, etc.
If you are asking specifically against SARS-Cov-2 , you either get moderna if you want the best vaccine AND want to be able to travel around, or you get sputnik V (2 doses, not sputnik lite)
Re: (Score:2)
What do you think about diseases that might have disappeared in the ancient past, but I might be vulnerable to now?
Re: (Score:2)
What do you think about diseases that might have disappeared in the ancient past, but I might be vulnerable to now?
I specifically listed Tuberculosos and Leprosy. :-P
that should be indicative enough of my position on that ;-)
Re: (Score:2)
Good point. What about, should I bring Ivermectin?
Re: (Score:2)
What language would you recommend for it, and given that migrating to a different language is a significantly larger undertaking than migrating from Python2 to Python3, who would undertake it? Should it be written in Perl, Ruby, Rust, Go, C? And what is wrong with Python3?
Re: (Score:2)
And what is wrong with Python3?
A) It's Python
B) I'm allergic to languages/libraries that don't respect backward compatibility. They're nothing but trouble.
Re: (Score:2)
It costs time and money.
What were they expecting? Even as a simple private citizen who never used Python professionally, I have a bunch of scripts that are essential to my machine running that I probably wrote a decade ago, no longer fully even comprehend of what they do and where they are and I certainly don't want to rewrite them and possibly introduce regressions. I once tried to see what happened if I disabled the unsupported python2 interpreter and my system could not boot, and I do not have the time n
Re: Why? (Score:3, Interesting)
Re: (Score:2)
Do you have an example of that?
There is also a difference between a small break that will only affect very minor edge cases compared to something that will surely necessitate rewriting almost every script.
Re: Why? (Score:2)
Re: (Score:3)
That does not necessarily mean that things break but perhaps simply that it declared 3.9 in it's shebang.
The reason for this is because every single dependency and library needs to be installed separately for each version. This is also annoying with Python which forces one to declare #!/usr/bin/python3.9 rather than simply python3, as an update to 3.10 will break one's entire system then due to various missing dependencies that need to be installed again.
Re: Why? (Score:2)
Re: Why? (Score:5, Informative)
Note that even 'minor cases' may cause breakage across third party libraries and you have to either fix their code and potentially fork them or hope they go and make the required minor changes.
But for some examples:
socket.timeout.foo = 1 This is fine in 3.9, forbidden in 3.10. The specific example is silly, but some libraries did depend on being able to modify socket.timeout and couldn't run in 3.10.
The asyncio module came out with loop parameter, then later made the loop parameter forbidden. The loop parameter at one point was *required* but later *forbidden*, so code trying to use those capabilities either have to forgo the convenience methods and go for the more tedious interface, or try one then except to the other.
The asyncio added support for letting users of the convenience function for creating a udp socket indicate they want SO_REUSEADDR set, and then made using that feature raise an Exception and refuse to work in a subsequent release (despite valid use cases for REUSEADDR, but the risk that someone might not understand it was deemed too high to let people use it in the interest of protecting them from themselves, so as a result you can't make a mdns responder correctly using the convenience asyncio function, again having to resort to manually making your socket and using add_reader instead).
For more, pick any 3.x "what's new" and look at removed and changed (including renaming parameters to core functions, taking a parameter that once could be specified by keyword and making it positional-only, changing exceptions thrown by core libraries in response to certain situations, and judging from the looks of it, if you are writing to the python C api, a whole ton more headache to try to navigate.
Re: (Score:2)
Re: (Score:2)
Would it be possible to write converter that automagically backported new Python code to older ones?
Re: Why? (Score:2)
Re: (Score:2)
Would it be possible to write converter that automagically backported new Python code to older ones?
Pretty easy, but the other direction seems more popular so far.
The real problem is that the libraries used would also need to be ported, and APIs change over time. So you'd have the wrong versions of various C libraries and other things. In most cases, without useful versioning to mitigate it.
If it is pure python, though; easy.
Re: (Score:1)
Maybe the Python developers don't give a shit if you switch or not, and aren't inclined to do a bunch of unpaid work to support you? Maybe they want a better language for themselves, and if you want a backward compatible language for yourself, it's on you to support it?
Maybe giant corporations that don't want to switch could trouble themselves to support the old version, rather than expecting others to do it for them for nothing?
The only rule here is that both you and the giant corporations are still respon
Re: (Score:2)
Even as a simple private citizen who never used Python professionally, I have a bunch of scripts that are essential to my machine running that I probably wrote a decade ago, no longer fully even comprehend of what they do and where they are and I certainly don't want to rewrite them and possibly introduce regressions.
Yep. I feel your pain.
Re: (Score:2)
Re: (Score:2)
My thought exactly, although at the same time I do understand some people have written a lot of stuff that would need significant editing/updating to move to Python 3.
I'm in a similar position right now, updating a lot of old code to run on current software (php, mysql, js, other odds and ends).
The code is generally good but some key functions have been deprecated and some now require some extra parameters, blah blah blah.
The thing is, it would run fine *forever* in its current environment, and it's tempti
Re: (Score:2)
Other than the fact that several LTS releases of Linux are still maintaining and shipping Python 2, no, there's no reason not to. Fortunately most of these LTS distros also have packages for Python 3. So I agree.
I moved a couple of years ago to python 3 for everything I do and it's been a mostly painless transition. I do think eliminating the print statement was it's biggest mistake, but other than that I have no issues. All the libraries and tools I rely on were ported to Python 3 a long time ago no.
Ubuntu 20.04 notes (Score:2)
This works on Ubuntu 20.04 LTS:
sudo apt install yt-dlp
I just double-checked to ensure I was using yt-dlp and I was. It seems some Ubuntu repo manager upstream has been paying attention for a while already.
Why? (Score:1)
Re: (Score:2)
1. No one cares about that because print() was fine in later python 2.
2. Frankly neither side of the python 2/3 bytes/unicode handling is exactly pleasant to work with. In python2, you had b'' and u'' strings where the default '' was b'', in python3 you have b'' and u'' strings where the default '' was u''. They both have benefits and drawbacks, and various core functions expect u'' vs. b'' in sometimes bizarre ways. For example, if you take a binary data stream and you base64 it into a text friendly val
Re:Why? (Score:5, Insightful)
it's hard to imagine such a stale environment really wanting brand new youtube-dl.
Youtube does not provide a stable public interface for downloading videos. So programs like youtube-dl periodically stop working and have to be updated.
I could well belive that there are crufty old media processing setups, that include the ability to import from youtube and similar sites and use youtube-dl to implement that functionality.
yt-dlp youtube-dl both already using Python 3 (Score:2)
Both youtube-dl and yt-dlp both use Python 3 on my Fedora machine. So no problems there with Python 3 compatibility. I suppose if someone wants to maintain a Python 2 version they are free to do so to support older, LTS distros.
It's not like they are forking anything so it only runs on Python 3. It's already on Python 3, and will continue to be so. There's no reason for anyone who uses them to be concerned about any of this.
Re: (Score:2)
I meant to say, it's not like they are forking anything so it only runs only on Python 2. It already works with Python 3 and will continue to do so.