[Draft] Client: Complete refresh for commands

[voetberg]

View issue #6639 for more details.

Location and naming all subject to change because this is a draft.

Key structural points -

• Makes the CLI its own module.
• Makes a "CLI" script (cli.py) which collects the client initialization, execution, and formatting output
• Makes an Abstract "Base Command", which all commands subclass to get their client connection, logger, argparse structure, etc.
• Puts each major "command" in their own file, with sub-commands as other classes in that file.

[voetberg]

So the current questions:

1. What on god's green earth do we name this thing (both as a module and the actual name of the command)

I'm making the executive decision and calling it rcom (for Rucio-Command, and also because it's funny to call a "romantic comedy" when all our releases are movie related.)

2. A lot of the existing rucio calls for when nothing is printed (e.g. added a rule or something) just print something like "Yay we did it!". This should probably go into logs instead in this format. What's the best level to go for there?

Just putting it at info - Logging's own documentation says logging should be used to "Report events that occur during normal operation of a program (e.g. for status monitoring or fault investigation)"

3. Upload and Download are the obvious ugly ducklings here as far as structure goes. Should we just go the route of ping and whoami and treat them as special cases?

Yes.

4. Where should this thing live in the rucio package? I think it makes most sense as a sub-module of rucio/client because they're pretty directly connected but I don't know if this has any upstream consequences I'm aware of.

It is just being put as a sub-module of client yes. To make the install simple, there is also added a script that just runs the main method in bin/rcom as well.

8. There are some odd situations where there's name duplication between commands and subcommands, but they get handled differently. (Biggest example is in did where dids can either be a single scope:name or a list depending on what you're doing.) How should this be handled in the help menu? Were I stand there's two main options - just find a way to replicate the option in each option group where its relevant (which keeps the help menu cleaner, but I haven't been able to find an instance of anyone doing this successfully) or make each command/subcommand show up in the main -h menu. (eg both account and account attributes have a menu entry instead of having attributes being nested in account).

I'm taking a cue from the existing Rucio-Admin and doing it exactly as I talked about above - only difference is that the command help will list the possible methods as well.