search

blackjack4494 / youtube-dlc

Command-line program to download various media from YouTube.com and other sites
https://blackjack4494.github.io/youtube-dlc/
The Unlicense
1.22k stars 13 forks source link

Drop most of the extractor to make the project more manageable #104

Open TheFrenchGhosty opened 4 years ago

TheFrenchGhosty commented 4 years ago

YouTube-DL has been in maintenance mode for years, and I think it's because there is just too much stuff in it.

In my opinion a proper fork of it should drop most of it's extractor, and only focus on public video website (youtube, dailymotion, vimeo).

It would be far better if it could support external extractor, that don't need to be taken care by the main developper.

YouTube-DL should only take care of the basis and people should add other features according to what they want.

PS: Thank you for the fork, I hope you will be able to maintain it for years.

samoht0 commented 4 years ago

YouTube-DL has been in maintenance mode for years, and I think it's because there is just too much stuff in it.

In my opinion a proper fork of it should drop most of it's extractor, and only focus on public video website (youtube, dailymotion, vimeo).

I disagree. There's allot work done by the community. The upstream primary maintainer @dstftw is unwilling to add more people with merging rights, because he is afraid of the code quality (if I got the reason right). A bit overboard, I think. But as a result the PRs are overflowing.

And this is resolved here, for now. When an extractor is broken and someone fixed it, why drop it with an open PR? Why drop an extractor, when it's still working fine? Maybe, if an exotic extractor is broken for some time and nobody is working on it, I consider doping as a valid option.

What do you mean by "people should add other features according to what they want"? Everybody is using an own fork? If so, makes no sense for me.

I'm RPM packaging youtube-dlc in fedora copr (moving from youtube-dl git) and consider it great as is.

TheFrenchGhosty commented 4 years ago

@samoht0 I get what you mean, but the thing is that this project is a one man project.

I think youtube-dl should focus on youtube (and similar site) and not bother with hundreds of websites.

Those extractors just create more work for a tool that's supposed to be used for youtube first.

What do you mean by "people should add other features according to what they want"? Everybody is using an own fork? If so, makes no sense for me.

Build support for addons, so that people could add support for other site themselves using the main software.

blackjack4494 commented 4 years ago

It's interesting and nice to discuss about this. I agree that there is a problem here. I wouldn't drop/remove most extractors out of nowhere. So far I have been thinking of alternatives.

  1. Plugin System
    There is youtube-dlc as the base program and if you want to download from a specific site ytdlc can check if there is an extractor already installed and if not look for one on the net. Otherwise fall back and try the generic extractor.
    I have no experience with plugins in python but researches a bit about this and it seems quite easy to do actually tho of course this will require work and some time but is a nice solution and can be quite dynamically expanded. This would also solve maintaining issues that arise as you would report to the extractor repository first and then ultimately to ytdlc. You could also define in a list what extractor to use if there should be multiple for one site.

  2. Offload some sites to dedicated programs This is actually extending the idea of the plugin system where you could simply pass along the work to a dedicated downloader to take care of it but still have ytdlc as a core component/manager.

In general I think a plugin bases / adapter pattern seems to be the best choice also for the future. There can be official supporter sites/extractors. Or you bundle ytdlc with some extractors preconfigured. Another advantage is that there are less updates needed for ytdlc itself since you would rather (auto) update the extractor you use which will ease maintaining even further.

We can create a branch or second repository where we test this by removing all extractors and trying different plugin solutions.

Just my 2 cents. Let me know what you think about it :)

To further extend on this. Maybe it's even possible to allow even core features to be plugins. I can think of integrating some upload functionality that extractors could utilize if they want.