Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
New maintainer needed #136
Comments
|
rg3 , Philipp's patch does not fix it. Most of the videos are still broken. Can you fix it this time please? |
|
Can you give me a few examples that don't work, please? |
|
I tried downloading the latest version so that I can give you videos, but could not for some reason (Get a 404 error on github) http://rg3.github.com/youtube-dl/download.html Here is one video that does not work...will send me you more shortly |
|
oops, actually that youtube url works, let me find you some that dont work, sorry |
|
I forgot to push the tags out and the URL was a 404. It's fixed now. |
|
I'm probably too naive, but I do think it is possible to create complex programs with lots of features. youtube-dl is nowhere near as complex as cpython, Linux, or webkit. Since everybody needs a different set of features, having many features translates to being useful for many people. Simplicity is great, but being useful trumps it. youtube-dl should be able to convert any URL to a video file or video playlist. Nothing more, but also nothing less. youtube-dl is missing two essential things required to grow:
I'd be honoured to co-maintain the official youtube-dl, but as you can read above, I'd take it into a different direction. Also, since I'm writing my Master's thesis, I won't have more than 5 hours per week until 2012. |
|
rg3: It seems to work. If it breaks on anything, will let you know here. Thanks. Features Vs complexity: I agree with rg3 that adding too many features is a bad idea, even at the youtube-dl level. Unless someone is ready to keep those features up2date. Perhaps the ones who request the features need to keep them up2date and then youtube-dl can automatically pull that code, test it, then append it to the youtube-dl file at the right place for download. If the test fails, that feature is out. I like the idea of unittests from phihag, but i think youtube-dl should be a place to assimilate other people's small pieces of well maintained code...and in itself be a small piece of code that downloads youtube videos. -- just my 2 cents. |
|
@anondavid Automatically pulling code is not feasible (for security reasons at the least). With a good test suite, the burden to either remove features or fix code is on the one who commits new code. |
|
Can anyone first make the code pep8 compliant and document it a little better? -- If someone has time perhaps? |
|
Actually the documentation looks decent already. But pep8/pylint could use some work : Global evaluation : Your code has been rated at -2.59/10. :-( |
|
@rg3 : I just did this "reindent youtube-dl" and then ran pylint...the new score is 7.27/10 ! Perfect! Can you try that and test it and see if you want to post that result instead of the current one. |
|
@anondavid youtube-dl may have some problems, but indentation is not one of them. Apart from having a better "score", which apparantly just depends on whitespace, the only effect of PEP8-ing the source is that developers have to reconfigure their editors to indent with 4 spaces instead of 1 tab. |
|
@phihag It's naturally possible to create simple programs with lots of planned features. Things start breaking when they get a lot of unplanned features. I actually think youtube-dl needs to be internally separated a bit more to be more useful and flexible, and I agree on the tests side. I normally check against a few bookmarked videos and URLs, but I don't check absolutely everything because I don't have an official test suite. However, I'm not here to impose restrictions or any specific condition to any possible future maintainer, so do not consider anything I say more than simple advice that can be followed or not. I can remark, however, that I think people like to be able to deploy youtube-dl by simply downloading the file and dropping it somewhere, and they do like the autoupdate feature, which works in most Unix systems if you have youtube-dl in a directory you control, like $HOME/bin. This is because, in some distributions, the package management tools do not repackage youtube-dl fast enough (others do, however), so youtube-dl is the kind of program they more or less have to or like to install manually. The version that works today may not work next week or tomorrow. Making that installation trivial is one of the keys to sucess. Another advice I can give from experience is that you need to be careful when introducing new features and not rely on many features from modern Python versions. This is because a part of the program users use it from a rented server where they cannot fully control what's installed. Recently Red Hat released RHEL 6.1 which features Python 2.6. OpenBSD and Debian are shipping that version too, but it's worth keeping an eye on those details. Not long ago some people were still using CentOS and Red Hat 5.x, which only had Python 2.4. |
|
@rg3, i just want to thank you for the hard work and patience you put into this project. |
|
phihag, as nobody else is willing to do this, I delegate on you from now on. |
|
Great, thanks! Since my fork doesn't seem to have caused great instability, I'll push it over here soon. |
Hello everyone,
As you may have noticed, I have almost stopped maintaining youtube-dl. This is due to time constraints. This year has been pretty intense professionally, I have several family issues open and I'm also trying to finish my master project (I should have done it 6 years ago when I finished my degree but I was dumb and left it pending, basically).
This forced me to get rid of a few time sinks and one of them was youtube-dl, so I simply left it there without looking at the pile of email that was accumulating and concentrated on the important stuff (sorry for not answering!). This situation will still last a few more months.
The program broke today so I was forced to release a new version, and used the fix from Philipp Hagemeister to make it work again (thanks for the code!). But, before it breaks again, I think the proper step is to give up maintainership and rely on someone with a bit more time to dedicate to the program.
If needed, I can still manage the master repository here and push out changes other people could send me. They only need to be rebased to the master branch to have clean pulls, but this would have to be coordinated with me so as not to steal more than a few minutes a week, unless the program breaks as it did today.
Thanks everyone and good luck to anyone who steps up.
It's been a good experience maintaining a semi-popular open source project and I learned a lot of things about interacting with my users and the way people work. The only advice I can give you as the old dog in the house is that I think I should have sticked to making the program work with YouTube alone, and I should really really have said no to many feature requests because the program has turned into a big monster for what it does. It should be much simpler, have much fewer options and do only one thing and do it well. Many times people request a small feature you can code in a few minutes, and you do it, and then someone asks for another feature and you think "if I said yes to the other feature, this one should be in too", and later you're buried in dozens of small features you need to maintain and do not respond to changes in other parts of the code as you had predicted. Today I would have also separated the output control from the FileDownloader, etc. The following article can be a good inspiration for maintaining open source projects.
"cat -v considered harmful" http://harmful.cat-v.org/cat-v/
Cheers.