Describe the bug
If there is any additional parameter, the DEM raises an error, except if the --help option is used.

To Reproduce
Currently, if I try to execute

dem list --help asd
dem ignores the extra asd parameter and gives back the expected result of the

dem list --help
but if I try to execute

dem list --all --env asd
I get back an error message highlighting there is an unexpected argument.

Expected behavior

The DEM should raise an error if any additional parameter has been added with the --help option.

Test all the commands with the --help option.

⚠️ Unsolved dependency: the Dev Env settings panel must be implemented first!

In the Dev Env settings panel, if the user selects the host, its value gets saved to the dev_env.json.

Describe the bug
The DEM should not accept any whitespace in the name of a Dev Env.

To Reproduce

1. Create a new Dev Env with the name “ “
   dem create " "
2. Set the parameters for the new Dev Env.
3. The Dev Env gets created with the name “ “.

Expected behavior

The DEM should notify the user that the name of the Dev Env can’t contain any spaces.

Implement the dem init [PATH] command.

The .axem directory

Project-specific DEM settings should be placed in the project’s root under the .axem directory. The .axem directory can contain a dev_env_descriptor.json file. This file describes a template Dev Env that can be used for the project. The dev_env_descriptor.json should have the same format as the available Dev Envs from a catalog or an exported Dev Env descriptor (with the export command).

Input parameters

PATH:

• If not set, the DEM looks for the .axem/dev_env_descriptor.json file in the CWD.
• If the input parameter is a directory PATH, use that as the root of the project.

1. The DEM must check if a dev_env_descriptor.json is available for the project. If not, report an error.
2. The Dev Env is already available locally: The DEM should ask the user to overwrite the locally available Dev Env descriptor with the one from the dev_env_descriptor.json file. If the locally available one is already installed, the user should be asked if they would like to have the locally available Dev Env to get uninstalled. If the user says no, the operation should be aborted.
3. Save the Dev Env descriptor to the dev_env.json file.

Currently, when the user creates a new Dev Env, they can only select from the “supported” tool types. The DEM doesn’t accept any Dev Env descriptor that is not included in the supported tool type list.

This behavior should be changed because it limits the usability for no reason.

The DEM should not check whether the tool type is supported or not. Any name can be given for a tool type.

The “supported” tool types are stored in the DevEnv class’s supported_tool_types class variable.

The installer should install the following dependencies if not yet available:

• python 3.10
• Docker Engine
• the DEM pip package

dem del-host NAME

Deletes the host from the config file.

If the NAME is an empty string, the DEM should raise an error. (Handled by typer).

If the DEM can’t find the NAME in the list of the available hosts, it should raise an error and abort.

The DEM should autocomplete the NAME with the already available host names from the config file.

Describe the bug
An unclear error message is presented when the path for the export command is ““ or “

To Reproduce

1. dem export DEV_ENV_NAME ""
2. The following error message is presented: FileNotFoundError: [Errno 2] No such file or directory: ''

or

1. dem export DEV_ENV_NAME "
2. The following error message is presented: FileNotFoundError: [Errno 2] No such file or directory: ''

Expected behavior

After the execution of the export command with ““ or “ as the path input parameter, the DEM should report: Error: Invalid input path.

dem uninstall DEV_ENV_NAME

1. The DEM should look for the DEV_ENV_NAME
   If it can’t find the Dev Env, raise an error and abort.
   If found, but the Dev Env is not installed. Raise a warning for the user and abort.
2. Go through all the required images and remove those, which are not required anymore by any other Dev Env.
3. In the Dev Env descriptor set the “installed” key to “False”.
4. If the DEV_ENV_NAME is an empty string, then the DEM should raise an error. (Handled by typer)
5. The DEM should autocomplete the DEV_ENV_NAME to the locally available Dev Envs.

dem install DEV_ENV_NAME

1. The DEM looks for the DEV_ENV_NAME in the local dev_env.json.
   If the DEM can’t find the Dev Env, it should report an error for the user and stop the execution.
2. The DEM pulls the images one-by-one from the registries to the local host machine.
3. The DEM should inform the user about the successful operation if all the images are pulled.
4. In the Dev Env descriptor set the “installed” key to “True”.
   "installed": "True",
5. If the DEV_ENV_NAME is an empty parameter, the DEM shall raise an error. (Handled by typer.)
6. The DEM should autocomplete the DEV_ENV_NAME with the locally already available Dev Envs.

The dem clone command will have a new purpose: it will copy the selected Dev Env descriptor from the catalog and save it in the local dev_env.json.

The new dem cp command should have the same functionality as the current dem clone one, meaning there is no need to modify the command logic.

Documentation: Commands - dem

The expected behavior (this is already implemented as the clone command):

1. The DEM looks for the DEV_ENV_NAME in the local dev_env.json file.
   If it can’t find it, an error should be raised and the DEM aborts the execution.
2. The DEM should check if there is already a Dev Env with the name of NEW_DEV_ENV_NAME.
   If the new name has already been taken, the DEM should ask the user to overwrite it:
   If yes, overwrite the Dev Env descriptor with the one coming from the DEV_ENV_NAME
   If no, abort the execution.
   If the name is not taken, then just create a new Dev Env descriptor entry in the local dev_env.json file.
3. If either the DEV_ENV_NAME or the NEW_DEV_ENV_NAME are empty strings, then the DEM should report an error and abort the execution. (Handled by typer)
4. The DEM should autocomplete the DEV_ENV_NAME parameter from the list of already available local Dev Envs.

dem delete DEV_ENV_NAME

Deletes the Dev Env descriptor from the dev_env.json and removes all required unused tools images.

1. The DEM looks for the DEV_ENV_NAME.

• If it can’t find the Dev Env, an error should be raised and the execution should be aborted.

2. The DEM runs the uninstall for the Dev Env. It removes all the tool images, which are not required anymore by any other Dev Env.
3. The DEM finally removes the Dev Env descriptor from the dev_env.json file.
4. If the DEV_ENV_NAME is an empty parameter, the DEM should raise an error. (Handled by type)
5. The DEM should autocomplete the DEV_ENV_NAME parameter with the locally available Dev Envs.

The requests.get() functions now wait for 1 sec before timeout. This value should come from the config file.

To learn more about autocompletion: Link

Autocomplete when typing in command:

_When the user types in dem and presses tab, then all the available commands should be listed. When the user starts to type in the name of the command, and presses the tab, only the matching commands should be listed.

These commands should be covered: info, list, create, rename, modify, delete, export, load, list-cat, add-cat, del-cat, list-reg, add-reg, del-reg._

Smart suggestion for arguments

dem info DEV_ENV_NAME
Auto complete for the DEV_ENV_NAME. Should list all the local and catalog Dev Envs.

dem list
Auto complete for the options: local, all, env, tool

dem rename DEV_ENV_NAME NEW_DEV_ENV_NAME
Auto complete for the DEV_ENV_NAME with the list of the locally available Dev Envs.

dem modify DEV_ENV_NAME
Auto complete for the DEV_ENV_NAME with the list of the locally available Dev Envs.

dem delete DEV_ENV_NAME
Auto complete for the DEV_ENV_NAME with the list of the locally available Dev Envs.

dem export DEV_ENV_NAME
Auto complete for the DEV_ENV_NAME with the list of the locally available Dev Envs.

dem del-cat NAME
Auto complete for the NAME with the list of the added catalogs.

dem del-reg NAME
Auto complete for the NAME with the list of the added registries.

dem add-host NAME ADDRESS
The user should be able to add a host.

NAME: name of the host

ADDRESS: IP or hostname of the host

The DEM should save this information in the ~/.home/axem/dem/config.json file:

"hosts": [{
  "name": "host name",
  "address": "host address"
}]

Example:

"hosts": [{
        "name": "strong",
        "address": "192.168.1.70"
    },
    {
        "name": "CI/CD",
        "address": "10.0.0.1"
    },
    {
        "name": "cloud",
        "address": "169.254.7.137"
    }
]

If the NAME is already takes, the DEM should ask the use if they would like to overwrite it or not.

If either the NAME or the ADDRESS command is empty the DEM should raise an error. (Handled by type).

dem list-host
List the available hosts from the config file.

If there is no host in the config file, inform the user that no remote host availalbe.

⚠️ Unsolved dependency: the Dev Env settings panel must be implemented first!

In the Dev Env settings panel, if the user selects the host, its value gets saved to the dev_env.json.

User shall be able to modify single images of the Env by a command:

dem modify DEV_ENV_NAME TOOL_TYPE TOOL_IMAGE
Where

• the DEV_ENV_NAME is the Dev Env to modify
• the TOOL_TYPE is the tool type to modify or add
• the TOOL_IMAGE is the new tool’s image

DEM should handle at minimum the following error cases:

• Dev Env exists locally?
• Img exists locally or in the registry?

The DEM should autocomplete the command and the arguments:

• DEV_ENV_NAME: the locally available Dev Envs
• TOOL_TYPE: the tool types already present in the Dev Env
• TOOL_IMAGE: the local and registry images

dem clone DEV_ENV_NAME

1. The DEM looks for DEV_ENV_NAME in the added catalogs.
   If it can’t find it, an error should be presented for the user and the DEM stops the execution.
2. The DEM saves the Dev Env descriptor to the dev_env.json file.
   If a Dev Env already exists with the name DEV_ENV_NAME in the local dev_env.json the DEM asks the user what to do.
   Overwrite it: the Dev Env descriptor in the dev_env.json gets overwritten with the one coming from the catalog.
   Abort: the DEM stops the execution. The original Dev Env descriptor remains in the local dev_env.json file
3. The DEM finally informs the user about the successful clone operation.
4. If the DEV_ENV_NAME is an empty string, the DEM should raise an error. (Handled by typer)
5. The DEM should autocomplete the DEV_ENV_NAME parameter from the catalog’s available Dev Envs.

Is your Documentation request related to a problem? Please describe.
A user always frustrated when trying to find specific parts of readme

Describe the solution you'd like
A Table of content

Additional context
Add Table of Content and Contributors to Readme

would love to work, please assign