Isn’t youtube-dl already updated all the time to keep up with scraping changes? I don’t understand why this would claim to be more maintained?
Anecdote: youtube-dl still works for all the sites I'm using it for.
I'm not payed for this, I'm not even thanked for this most of the time, so I'm certainly not going to set any deadline.
But forking might be a solution, if you can give the necessary horse power for the long run.
Most can't.
The other day, I was trying to use a Python library to scrape some stuff. It kept breaking. I looked on the issues page and there were many, essentially useless bug reports asking them to fix the issue. I opened up the script and changed about 7 lines and it worked fine.
At times I imagine there could be some kind of "I know how to report bugs"-certification that people could somehow earn. Projects could then use this as a barrier to prevent getting too many useless issue reports.
The problem really goes both ways - as a software dev I'm disincentivized to report detailed bugs to projects, because there's a high risk it will get drowned out in the noise.
Some projects have quite specific templates for reporting issues. This helps a bit, but you still need someone to go in and remove issues that don't match the template, and few people want to volunteer for that work.
I mostly use GitHub to find off the shelf solutions to whatever problem I’m having or to avoid doing the work myself. If I run into any problems I have with something from there, I either try and fix it by tweaking the repository, using another, or just building the thing myself. I think the last time I reported an issue on an external repository was because of something I was made to use at work.
No code, no PRs, just a way for the public to create Issues.
Not sure what this means for the "culture of code" other than things are blurring...
https://github.com/ytdl-org/youtube-dl/issues/26462#issue-68...
Unfortunately, can't find a way to link to the edit in question directly. You'll have to click once there to see the diff.
In practice, I find it really useful to tidy up the top message of a bug report (but /really/ like seeing history of it). I also see cases where users spam raw logs into updates and tidying it up (perhaps making the log portion an attachment or changing formatting) makes it much clearer for future-you and other collaborators.
Are those issues you describe fixed in not merged PRs in youtube-dl and fixed in merged PR in youtube-dlc?
[1] https://github.com/ytdl-org/youtube-dl/pull/18230
Not saying forks should never happen - streamlink and KeepassXC are examples of great forks off the top of my mind - but you can't judge just on anecdotal stale PRs.
ydl has 700 open PRs, not 25k+. ydl hasn't had 25k+ PRs in its lifetime either, it's had 4k: GH issues and PRs are the same object, so the sequence is shared.
It's not like the forker inherited all the open issues/PRs, they just dropped them all.
Getting popular and having the masses leave a bunch of issues/PRs is hard. Reviewing code is hard and takes more expertise than writing it. A lot harder than reviewing your own PRs on a motivated (for now) fork.
That's wrong, most of the recent commits in the fork are merging branches from a lot of other repos. GitHub doesn't have a mechanism for inheriting a project's pull requests when you fork, but that doesn't mean they're automatically "dropped", since you can still merge the corresponding branch.
Although totally agree reviewing can be such a pain..
As someone who has tried to contribute to YouTube-dl in the past, the absolute disinterest I received and complete lack of follow up on simple bug-fixes caused me to completely dismiss YouTube-dl as a FOSS project worthy of my time.
And I say that as someone who sends PRs to projects I’ve visited once, over tiny things like typos or lack of installation/build instructions in the readme.
Some of my PRs received a crazy all-or-nothing treatment, asking me to fix huge, long-standing bugs nobody had fixed for years, instead of accepting a 2-line diff which did a provider-specific workaround which solved a real bug, but seemingly not in the “right” way.
Completely toxic and hostile.
That someone has started a community-fork with a more welcoming and pragmatic approach does not surprise me in the least.
Maybe I'll have more luck with this fork.
https://github.com/ytdl-org/youtube-dl/issues/23860
He closed it without even addressing the issue of him closing the related issues that I explicitly brought up. There are scores of issues describing the same issue, but all of them are closed, and more of them are still being submitted. This has been going on since April of last year.
It's making me realize that sometimes a fork really is the only way to get around the problem that you're not in control of the project and there are bugs that many people need to be fixed.
Verbatim from my comment: "the youtube.com undocumented api"
Thanks for reading.
In fact I'm pretty sure I've seen youtube-dl mention downloading the HTML page when using it with YouTube, so maybe it does even scrape YouTube.
Please explain.
YT constantly changes how it masks access to the underlying resources with JS updates that break these libraries. The most frequent updates are to fix this.
Keeping software well maintained involves a lot of saying no, unfortunately.
Right... and the youtube-dl maintainers aren't doing that.
So what is it about youtube-dlc that makes it special compared to the other 12k forks? You scroll down to the readme and it's the exact same, just that someone replaced -dl with -dlc.