Test: Fix CI tests

[cadenmyers13]

Problem

Improve the CLI testing

sub issues:

• feat: cli print function and test #59
• feat: cli copy function and test #58

Proposed solution

Step 1 is to figure out at a very high level what the task is. this is the UC process. Here are some examples. Parentheses are possible user cli syntax:

general cmi commands

listing packs/examples/profiles, seeing what packs/profiles are installed. etc.

UC 1
1. user wants to know what packs are available 
2. user asks cmi (cmi pack list)
3. cmi lists them 

UC 2 
1. user wants to know what examples are available 
2. users asks cmi (cmi example list)
3. cmi lists them

UC10 
1. user wants to know what packs they have installed
2. user asks cmi
3. cmi lists the installed packs

UC11 
1. user wants to know what profiles they have installed. 
2. user asks cmi 
3. cmi lists the installed profiles

commands for copying examples

UC 3 
1. user wants to copy one of the examples
2. user tells cmi (cmi copy <ex>)
3. cmi copies everything to cwd to do the example

UC 12
1. user wants to copy example to a specific location in there directory
2. user tells cmi what directory to copy what example to
3. cmi copies that examples 

UC 4 
1. as UC 3 but user specifies a different target file-path
2. cmi copies everything to target (cmi copy <ex> --target-dir path/)

UC 5
1. as UC 4 but user specifies a list of examples at the same time (cmi copy <ex1>  <ex2>)

UC 7
1. as UC 4 but user wants all the examples from pack X (cmi copy <pack>)

IC 8
1. as UC 7 but user wants all the examples from a list of packs (cmi copy <pack1> <pack2>)

UC 9 
1. as UC 8 but user wants all the examples from everything (cmi copy all)

Next is a discussion of which UCs we want to implement. Roughly speaking let's assume we want them all.

Next is a first cut at architecture. Good to discuss it a bit, but what structure do we want, data objects, etc. to cover as much of the UCs as possible? What is a list of tasks that the code would have to do to accomplish the tasks? e.g.,

generate a dict of packs and examples dynamically from all the examples it finds.
design CLI for the above tasks
write functions that pull from the examples dict for the various listing and copying tasks.
and so on....

Next is discuss and finalize these things and we can start on the code.....

[cadenmyers13]

@sbillinge Copied everything here. I see where I was misunderstanding. I put example commands in parenths next to each UC. I also added UC 6. We might want to not include it because the user could simply do cmi copy example <pack1>/<ex1> <pack1>/<ex2>. We can discuss syntax further but I think they are all mostly fine. What do you think?

[sbillinge]

we are not really testing the CLI. But the flow is from behavior -> architecture/design -> unit tests -> functions.

Step 1 (behavior) of course has a UI component but we are not after writing tests of that.

[sbillinge]

OK, I like UC6 though it may not pass the cost-benefit analysis unless it is cheap to implement. Let's leave i there for now,

Let's now discuss architecture (it is a bit easy because we already implicitly thought about it).

1. data-container: dict of examples = {k: v} {pack: list of egs} and
2. function to build examples dynamically from those available at examples_path
3. The listers will just be functions that break out info from examples and pretty print them
4. The example-copiers will need pull info from the examples dict but they will need the path to the example. We either need to store this path information in another dict or we can dynamically build it given the pack and example name. We may wan to discuss the plusses and minusses of these two approaches. The glob will give us the path so it is easy to build that dict and that may be more robust?
5. We need to discuss the best CLI so that it is intuitive and easy for users to request the different UCs. nargs allows lists of things. We could let them list packs and they get all examples from those packs. Or list examples and they get those. But it will break if there are examples with the same name in different packs. That is a brittleness that we could probably do without.

[cadenmyers13]

@sbillinge

We either need to store this path information in another dict or we can dynamically build it given the pack and example name. We may wan to discuss the plusses and minusses of these two approaches. The glob will give us the path so it is easy to build that dict and that may be more robust?

I think building the path from the dict would be fine and probably easier to code.

nargs allows lists of things. We could let them list packs and they get all examples from those packs. Or list examples and they get those. But it will break if there are examples with the same name in different packs.

nargs sounds good to me. If we require the user input to be in the form <pack>/<ex> I don't think it should break because something like cmi example copy pack1/ex1 pack2/ex1 would give the list ["pack1/ex1", "pack2/ex1"] which are distinct, right?

[cadenmyers13]

@sbillinge Here's my idea for the copy architecture. We have a small copy function for each UC (UCcopy_function). map_pack_to_example() is called in each copy function, and each copy function takes a str as an argument where this str is something like pack/ex.

Then we have a function (copy_logic_function) that contains all the logic which determines which copy function is called. The copy_logic_function would be called by main() or these functions can be directly called by main. I think this can be integrated into our current code structure. This could look something like this:

map_pack_to_examples(Path)
   return dict[str: List[str]]

UC1_copy_function(str):
   pack_ex_dict = map_pack_to_examples(Path)
   # 1) code that gets the corresponding example from pack_ex_dict
   # 2) code that globs and copies the code to the cwd
   return

UC2_copy_function(str):
   pack_ex_dict = map_pack_to_examples(Path)
   # similar to above
   return 


copy_logic_function():
   if string_format is "pack/ex":
      UC1_copy_function
   if string_format is "pack/ex" or "something/else":
      UC2_copy_function()
...


# This is the current main() function, maybe can just call the UC copy functions directly here
def main(argv: Optional[List[str]] = None) -> int:
    """Run the CMI CLI.

    Parameters
    ----------
    argv : list of str, optional
        Argument vector to parse. When ``None``, defaults to ``sys.argv[1:]``.

    Returns
    -------
    int
        Process exit code (``0`` success, ``1`` failure, ``2`` usage error).
    """
    parser = _build_parser()
    ns = parser.parse_args(argv)

    set_log_mode(ns.verbose)

    if ns.manual:
        open_manual_and_exit()

    if ns.cmd is None:
        parser.print_help()
        return 2

    if ns.cmd == "example":
        # logic here that handles copying
        return _cmd_example(ns)
    if ns.cmd == "pack":
        return _cmd_pack(ns)
    if ns.cmd == "profile":
        return _cmd_profile(ns)
    if ns.cmd == "install":
        return _cmd_install(ns)
    if ns.cmd == "env":
        return _cmd_env(ns)

    plog.error("Unknown command: %s", ns.cmd)
    return 2

I need to learn/better understand the argsparser stuff, so this will be refined but just as a general starting point

[sbillinge]

We are not yet ready to design the code, we are more still in the phase of thinking about data types and the API. What functions do we want. Then we will write tests, then the code.

[sbillinge]

Here your input is very helpful as it is how will folks use it. How about this.
User types:
UC1 and UC2:

   cmi info

for all the others we could do

    cmi copy <name>

if is a pack we return all examples in the pack, if it is an example we return that example. If we find two examples with the same name we return all that we find. If it is a list, we apply the same logic to everything in the list. If it is is "all" we return everything.

This seems like it would be easy to use and convenient and get the job done.

For the case where we copy it to another target directory, we could specify --target-directory as an optional parameter.

How does that sound?

[cadenmyers13]

For the case where we copy it to another target directory, we could specify --target-directory as an optional parameter.

@sbillinge I like this idea a lot. We should definitely implement that.

Are we looking to completely redesign the CLI? Tieqiong put some effort into designing a specific set of commands that work well (cmi pack list, cmi example list, cmi example copy <ex>, etc.). If you need a refresher on the commands we have them listed in docs: https://www.diffpy.org/diffpy.cmi/getting-started.html.

It seems that this is moving towards a different design which might be more effort than its worth. I understand of we want to refactor Tieqiongs code to make it stronger and implement tests, but I think the commands are there.

Edit: Had a convo in person about this, its clear to me what our objective of this is.

[cadenmyers13]

cmi info

1. finds all profiles and packs
2. determines if profile or pack is installed or not
3. finds all examples
4. Pretty prints everything it finds

cmi copy <ex>

1. finds example path
2. copies example to cwd (default) or to dir specified by user

[cadenmyers13]

@sbillinge can you add this issue and the two new issues i created (linked above) to the release milestone when you get the chance? Thanks!