Refactor socos to add an interactive shell

[stefankoegl]

I've more or less completely refactored socos.py in order to add an interactive shell.

You can now do something like the following (comments added manually)

# start interactive shell without parameters
$ python socos.py

# enter invalid command, and a list of valid ones will be dynamically created
socos> asdf
Unknown command "asdf"
Valid commands: play, set, stop, volume, previous, info, queue, pause, list, next, current, state, partymode, exit, unset 

# no "all list" anymore
socos> list
192.168.0.135
192.168.0.129
192.168.0.132

# set a "current" speaker, all following commands will use it
socos> set 192.168.0.135
socos(192.168.0.135)> info
uid: XXXXXX
software_version: 12.9-12345
zone_icon: x-rincon-roomicon:xxxxx
mac_address: 00:11:22:33:44:55
hardware_version: 1.2.3.4-5
zone_name: ABC
serial_number: 00-11-22-33-44-55:6

# remove the current speaker
socos(192.168.0.135)> unset
socos> volume 192.168.0.135
19

socos> exit

The shell supports readline features such as arrow-navigation, Ctrl+R search, etc.

All other features should have been preserved. Error handling should still be improved, though. Tab-completion is also still missing.

Please let me know what you think.

-- Stefan

[petteraas]

should probably be idx instead of args

[petteraas]

I've tested the various functions both in 'shell' and 'interactive', found some bugs that I've commented, but I generally like the idea!!

I do however have one other input after reading the code, should some of the functions be moved to a ( or multiple ) separate class(es). That way we could start looking into unit-testing some of this code, and it should theoretically end up a bit cleaner.

[stefankoegl]

Thanks for your input! I think I've addressed all comments so far.

I do however have one other input after reading the code, should some of the functions be
moved to a ( or multiple ) separate class(es). That way we could start looking into unit-testing
some of this code, and it should theoretically end up a bit cleaner.

I agree that the file is quite big already, and a bit refactoring won't hurt... Do you have any suggestions on what exactly to move?

[petteraas]

I think we can split this in a step by step process, start by adding a Player class and move all the 'commands' to it, so the current socos.py ends up as a form of runner for this class ( for now socos.py can still take care of input, cli vs interactive etc ).

Next step might be to move everything related to volume to a separate Volume class that is then used in the Player as we have multiple volume related functions.

Further down the road we can split between 'state changing' type of functions like play,stop,next etc and information returning functions like print_queue, print_current_track_info, but I would postpone this until we see a need for it.

[DPH]

+1 Great work. Couple of minor additions that would be nice (but no reason not to pull this):

1. the help should format the valid commands onto more than one line as it already wraps, and I anticipate more will be added. Also we should say it is command followed by an optional IP address (eg
   Usage: command {ip-address}
   Commands: xxx, xxx, xxx, xxx, xxxxxx, xxxxx
   xxx, xxx, xxx, xxxxx, xxxxx , xxxx

2. the list command would ideally include the zone name. An option would then be to use zone name or IP in any of the commands. I know it requires extra network traffic to get it, but it is more usable!

Cheers David

[stefankoegl]

Thanks for the review so far! I've added a "help" command in 98a813c which addresses parts of @DPH's first point.

I'd suggest to merge this rather soon (in a couple of days) if there are no objections. I will then work on the other suggestions in separate pull requests.

[petteraas]

+1 for merge in a couple of days.

[DPH]

+1 looks good

[stefankoegl]

Thanks everyone!

I'll work on additional features / refactoring soon.

[petteraas]

except for #9 everything else seems to be working nicely after the merge :)