mayank-ramnani
commented
3 years ago I just found this project, and am thankful to you for making it! I was going to build my own sync tool if I hadn't found yours, and the language I had decided was python. Python3 is easily available everywhere, and it has a native library for youtube-dl as well.
As first mentioned here I have, in the past, been thinking about maybe rewriting the project in another language. The main motivation here is that I still have new features planned but thinking about implementing them all in bash in the same way I've been dealing with things in the project so far would feel like implementing the basic idea for 5 minutes and then spending 3 hours testing and debugging and handling weird special cases that are only special because bash decides to interpret some kind of whitespace or dotfile or asterisk in fuck knows what way. Handling the output of youtube-dl is something that is not happening at all, and I would not even attempt doing that with bash at this point. I am not saying it's impossible to continue this project as a bash script, but I feel like the future plans might cause too much bash overhead to be part of the entire ordeal, which I might not be motivated enough to actually approach.
Since I have no idea who uses or how many people use this project, and what their requirements are, I am not sure what the actual pros and cons might be with regards to
In particular, I've been thinking about re-doing everything in node.js, potentially as a TypeScript library and then implementing a CLI user interface that uses the library to manage the local archive. This should be way more maintainable. I see JS/TS code as much cleaner and less "noisy" than bash. It's easier to avoid bugs caused by formatting or misinterpreting things like paths. The UI might become much cleaner with relatively simple code. Things like the status command could show more useful information. We could switch to an actual database (even if it's just sqlite) instead of loose files (although this is optional and I don't know if it would help with anything in particular). Writing a web UI and adding support to, say, a NAS platform and thus allowing to control the operation via a simple-to-use end-user interface would be relatively easy if you could just interface the JS/TS code directly. The main contra argument would probably be the fact that not every platform can run this and it might actually be a dependency that could prevent the project from being used in certain cases. I am not sure if those cases matter.
If you're using youtube-sync, I would find it helpful if you could voice your opinion on the matter, as this change might (or might not) affect how you will use youtube-sync down the line.
I still see this script as not exactly important to many people or even archivists in particular, and I am not sure if targeting any kind of audience should be part of my scope. After all, this is still a small script that I initially wrote for my own purposes of archiving YouTube channels which I like and assumed it might come in handy for other people. There was no reason not to release it. On that term, I could just do whatever I want with it, but I feel like giving actual users of the script in its current state a way to express their wishes or requirements would make more effective use out of my time. (As in, considering other users' views might make this tool more suitable for more archival applications, big and small alike.)