arichtman / foxops Goto Github PK

Look into both Python-supplied and python-gitlab exceptions to see if there's specific types for missing results or ambiguous results

Typer doesn't seem to support the features we want and is still too nascent. Click is commerically supported, has more features, more complete documentation, and is version 8.x

Task is to select testing framework. Implementation is out-of-scope. Ensure decision register and any other documentation is updated.

environment variables? singleton config object? config as YAML? Assume system and user locations? option to specify a config file? subcommand for management of config?

Presently if we pass the envvar argument when decorating with an option it works, but auto_envvar_prefix should be defaulting that argument.

Exploratory work to assess and select an error handling approach e.g. use out-of-the-box, monadic, or other

Presently the Gitlab.projects.list() function search doesn't seem to understand f"{group}/{project}" syntax for searching. As such, many more results than desired are being returned.

When run mkdocs locally it generates side bar and top navigation. The github action doesn't and so you can only see the one page you land on :'(

What it says up there. array_object[0] is ugly - change my mind

Some basic documentation outlining what the goals of this project are, how it plans to achieve it, maybe a road map would help too.. Don't go overboard but use this to have a think about the details and direction.

Use Typer module to create foxops project get subcommand

if it's only holding things needed to initialise the connected/authenticated gitlab object instance then we can isolate the config to main.py and just make the object available after that. Unless there are things like verbosity we want to make available?

Explore and decide which argument parsing module/framework to use. argsparse, typer, plac, docopt etc
Must update decision register

get the main function pulling a gitlab repo's metadata or information

Broadly speaking the configuration object should only be things that the user can set, and not a vehicle for global static constants. Furthermore, there appears no need for global static values anyhow.

Take some time to think about and write down how we actually want this CLI to work, and what a typical workflow would look like

In order to reduce code duplication we should be able to say that for all subcommands the following options may apply e.g. --verbose. For arguments for all subcommands it may be better to store such things in configuration. Needs some playing with and thought.