Since we now have pretty logs for them, the exception (which would be a CalledProcessError) would be generally pointless. However, the return code may be useful so that is kept.
This results in a noticeably faster speed cancelling segmented track downloads on CTRL+C and Errors. It's also reducing code duplication as the dl code will now handle the exception and cleanup for them.
This also simplifies the STOPPING/STOPPED and FAILING/FAILED status messages by quite a bit.
This is so that I can start to log information after the track listing. It's also not necessary to have the try catch within the loop, when both methods will have exited the loop.
It's not used by devine itself, but it's still a sub-dependency. Remove from being an explicit dependency in case the sub-dependencies ever remove it as well.
Since I'm using `futures.as_completed()`, it will never ever for loop over all tracks and segments and will forever be stuck in the primary thread of the operation. I.e., main thread for the download track threads, or the track thread for the download segment threads.
I've also removed all future cancelled checks as they will never be cancelled before they get the chance to run, because no future cancel calls are made anymore.
I've removed asyncio usage as it's generally unnecessary. If you want to run aria2c under a thread, run it under a thread. In the case for devine, this would take another thread, and would be another thread layer deep. Pointless. Would affect speed.
With this change I've been able to improve the aria2c progress capture code quite a bit.
While console.log is currently removing the need for `Padding(..., (0, 5))` as it is overwritten to do it automatically, but in terms of purpose the `console.print` function is more logical.
I hope to find a way to automate the padding within console.print in the future, but for now this will work.
It seems the commit I made to do this change initially seemed to help, it was actually pointless and issues I had were caused by other problems.
For consistency it seems best to stick with the logging module with the RichHandler applied. Using just console.log means being unable to control the log level and which level of logs appear.
This pull request adds the features that are detailed in this issue:
https://github.com/devine-dl/devine/issues/2
Also changes some debug logs to info logs, as the information would generally be wanted. Also changes some logging logs to console.logs.