some cli options should actually be sub commands

[Granitosaurus]

Some options are clearly just commands and should probably be treated as such:

e.g.
nordnm sync --update should be nordnm sync update and nordnm list --countries should be nordnm list countries.

What do you think of porting cli logic to click instead of imo messy argparse? Click would also allow easy decorator solutions for issues like: #70

I'm very fond of click interfaces myself and could probably work on a PR for this :)

[chadsr]

I totally agree that most arguments should be sub-commands. I will admit that I mostly settled for the optional arguments due to how frustrating argparse can get. I have not come across click before, so I will look into porting to it. If you want to work on it yourself, that is also welcomed. The whole initiation should probably be cleaned up at the same time.

Thanks for the feedback!

[chadsr]

And with the sync --update option, I was actually thinking of removing it and adding a flag such as --no-update instead. Since the last version, nordnm already only downloads new configurations if they have changed (instead of every time), making this acceptable to be an automatic routine, which can be optionally disabled.

[chadsr]

@Granitosaurus let me know if you would like to be assigned to this issue (If you are wanting to work on a PR), otherwise I will assign myself and get working on it when I have some time.

Thanks!

[Granitosaurus]

@chadsr Yup, you can assign it to me. I've already started, though I might have gone a bit to far with refactoring and such. Either way I'll submit a WIP PR and we can discuss what's good what's bad there :)

[chadsr]

That's totally fine. A lot of the current codebase is in need of major refactoring. I have been holding it off, because I still have the intentions to rehaul the whole project into a provider-agnostic package (not just for NordVPN) some time soon. Feel free to break down your work into multiple PR, so we can discuss each group of changes separately.

Thanks!

[chadsr]

Closing for now, as further discussion can be moved to PR #74.