spotDL's backend is ready. It still needs a CLi
* @phcreery working on this. *
I have been working on a personal implementation of this. Is this what you have in mind? It's definitely not done and has a couple of bugs.
Is this for the new version or current one? This issue was created for the new version that's under dev.
I have been working on a personal implementation of this. Is this what you have in mind? It's definitely not done and has a couple of bugs.
And No, not what I was thinking, i was thing much simpler. See the fork (it's a muck, but the usage was what I was thinking of)
This was for the old version. Okay.
Are you interested in building the cli for the new version?
Yea, I would like to help
Cool. So basically I had a crappy time trying to get the cli to work with multiple processes. And the total rework had some major problems (like, you simply couldn't package it for pypi) but at the same same time has ~100% accurate search.
At the moment I'm reworking the new version.
You could start up on the cli by figuring out how it's going to play out visually.
Like,
If searching it goes like this,
$description or a mockup screenshot you cooked up with python or paint.
If downloading it goes like this
$description or a mockup screenshot you cooked up with python or paint.
And get familiar with the dependencies you might want to use for the cli.
If your interested you can look up the progress on the rework at my repo. The docs are practically useless as of now, so # just look up __test__.py over there.
I see that __test__.py is being used for testing purposed on the songObj use. Is this all the progress in the v3 rework?
I am a little confused as to what is going on in your fork. Looking through the commit history, I noticed there once was a directory containing the old code, has it all been replaced already? Basically what is the current status of the rewrite, and it it all being put in your fork?
(⊙_⊙;) Well, I actually finished a fully working version. The only issue was that (a) the whole downloads handling was not super reliable and (b) when I tried to build a distribution, it simply would not work. The cause of both problems is that I'm using multiprocessing to speed up the work. Considering that I have to rewrite almost half of the codebase to fix it, I figured I might as well rework the whole thing. which is what you see now.
You can check out the workings of the completed (but un-distributable) version at this commit.
My current work could use some docs I guess. I put that up as soon as possible.
__NOTE__
As to the CLI, it should be able to take inputs from multiple processes (which is what kind of makes the whole job a pain). The most convenient way to do this that I found is by implementing a multiprocessing.BaseManager, as of now (10/09/2020 12:16, i.e. the moment of writing this), I'm writing up code to display a tqdm progress bar as downloads progress in parallel processes.
If its your intension to focus purely on the interface the user interacts with, you can ignore the whole multiprocessing problem - you'll get progress bars that handle that for free by default
You might find looking as these (slightly old) files a pretty good place to start interfaces.md and __main__.py (the original CLI I built)
I realize that I may not be very clear in what I'm saying ¯\_(ツ)_/¯, feel free to ask me about whatever you want to know.
No sweat! Okay, I see now. I was looking at the number of files in v3 (11 .py files) compared to the ritiek master branch (~46 .py files) which is good in terms of cleanup! I just needed to get a feel of what the progress is to know what I have that needs done.
Thanks for the help!
cool. Just a note, don't focus on v3. spotdlv3 cant be packaged (cuz of the afore mentioned multiprocessing problems) look into the spotdl folder instead.
An ad-hock temporary (may be permanent) CLI is ready. For release purposes, it is ready.
Most helpful comment
Yea, I would like to help