Add hugie config modify sub-command (resolves #41)

[ivyleavedtoadflax]

Description

• Adds the hugie config modify command (resolves Add funcionality for config editing #41)
• Adds tests
• Updates docs

Checklist

• Tests added
• Relevant issue mentioned
• Documentation updated

[nsorros]

Dont forget to tick the checklist

[ivyleavedtoadflax]

@nsorros maybe you forgot to approve this?

[nsorros]

shouldn't this contain config?

[ivyleavedtoadflax]

No, it's a separate sub command, so it should be in docs/config

[nsorros]

maybe better to test that some data are still there instead of lost

[ivyleavedtoadflax]

will add

[ivyleavedtoadflax]

Added in 667d83a

[nsorros]

i had envisioned this slightly differently and closer to

hugie configure --profile client-api-1

this would kick an interactive session where you can set some of the variables you define

    accountId: str = typer.Option(
        None, help="ID of the account (for private endpoints)"
    ),
    name: str = typer.Option(None, help="Name of the endpoint"),
    type: str = typer.Option(
        None, help="Type of endpoint, one of ['public', 'protected', 'private']"
    ),
    accelerator: str = typer.Option(
        "None", help="Accelerator to use. One of ['CPU','GPU']"
    ),
    instanceType: str = typer.Option(None),
    instanceSize: str = typer.Option(None),
    minReplica: int = typer.Option(None, help="Minimum number of replicas"),
    maxReplica: int = typer.Option(None, help="Maximum number of replicas"),
    framework: str = typer.Option("huggingface", help="Framework to use"),
    image: str = typer.Option(
        None,
        help="Image to use when deploying model endppint. Must be string representing a valid JSON, e.g. '{'huggingface': {}}'",
    ),
    repository: str = typer.Option(None, help="Name of the hf model repository"),
    revision: str = typer.Option(None, help="Revision of the hf model repository"),
    task: str = typer.Option(None, help="Task of the model"),
    vendor: str = typer.Option(None, help="Vendor to use. One of ['aws','gcp']"),
    region: str = typer.Option(None, help="Vendor specific region, e.g. 'us-east-1'"),

the end goal being that if a user has these variables setup or if they have them as env variables (maybe for the future) then they can simply do hugie endpoint create.

maybe a middle ground is to have hugie config modify be more interactive? so at least the user is creating a config file interactively which they can use for hugie endpoint create instead of passing params. it should also work with a path that does not exist and create it.

[nsorros]

does it work with a path that does not exist?

[ivyleavedtoadflax]

No, it should fail. I will add tests and error handling for this.

[ivyleavedtoadflax]

Error handling already covered by load_json(). In order to create the file (if it doesn't exist), we would need to have all the other arguments set, otherwise the file would not be properly specified. I would leave this for the current PR and let's discuss about the next one in relation to #54.

Noe that I was also considering adding a hugie config create to create a skeleton config file. Perhaps these two will be related.

[nsorros]

I was also thinking that hugie configure should allow you to set those variables in a default profile and when the user tries to run hugie endpoint create they can leverage the default profile for most of those and only pass the information they want to change

[ivyleavedtoadflax]

I was also thinking that hugie configure should allow you to set those variables in a default profile and when the user tries to run hugie endpoint create they can leverage the default profile for most of those and only pass the information they want to change

I don't think a default profile will be very useful for a production setting. We want to be explicitly setting those things and recording them in Git, not relying on a hidden state that exists on someone's laptop.

This implements the second point you mention where you can specify an existing config file and make small changes to it on the command line making it easier to deploy and update deployments in CI/CD. The overwrite option allows you to save the new config out so that it can be stored in Git. We are already doing something like this in a Github action for one repo, so whether or not we add additional profile based functionality, I think we should merge hugie config modify so that that functionality is included in hugie, and doesn't need to be replicated elsewhere

[ivyleavedtoadflax]

i had envisioned this slightly differently and closer to

hugie configure --profile client-api-1

this would kick an interactive session where you can set some of the variables you define

    accountId: str = typer.Option(
        None, help="ID of the account (for private endpoints)"
    ),
    name: str = typer.Option(None, help="Name of the endpoint"),
    type: str = typer.Option(
        None, help="Type of endpoint, one of ['public', 'protected', 'private']"
    ),
    accelerator: str = typer.Option(
        "None", help="Accelerator to use. One of ['CPU','GPU']"
    ),
    instanceType: str = typer.Option(None),
    instanceSize: str = typer.Option(None),
    minReplica: int = typer.Option(None, help="Minimum number of replicas"),
    maxReplica: int = typer.Option(None, help="Maximum number of replicas"),
    framework: str = typer.Option("huggingface", help="Framework to use"),
    image: str = typer.Option(
        None,
        help="Image to use when deploying model endppint. Must be string representing a valid JSON, e.g. '{'huggingface': {}}'",
    ),
    repository: str = typer.Option(None, help="Name of the hf model repository"),
    revision: str = typer.Option(None, help="Revision of the hf model repository"),
    task: str = typer.Option(None, help="Task of the model"),
    vendor: str = typer.Option(None, help="Vendor to use. One of ['aws','gcp']"),
    region: str = typer.Option(None, help="Vendor specific region, e.g. 'us-east-1'"),

the end goal being that if a user has these variables setup or if they have them as env variables (maybe for the future) then they can simply do hugie endpoint create.

maybe a middle ground is to have hugie config modify be more interactive? so at least the user is creating a config file interactively which they can use for hugie endpoint create instead of passing params. it should also work with a path that does not exist and create it.

See my comment below on why I think that we need to rely on config files. We can add an interactive mode to config modify for the middle ground, but I think setting up profiles is the wrong way to go. The only corollary to this is that it might make sense to set some values in a common config file, such a cloud provider, etc., but this shouldn't be hidden in a local profile.

[nsorros]

See my comment below on why I think that we need to rely on config files. We can add an interactive mode to config modify for the middle ground, but I think setting up profiles is the wrong way to go. The only corollary to this is that it might make sense to set some values in a common config file, such a cloud provider, etc., but this shouldn't be hidden in a local profile.

Setting an interactive mode might be a nice user experience, add an issue if you agree and we can implement in a later PR

[ivyleavedtoadflax]

See my comment below on why I think that we need to rely on config files. We can add an interactive mode to config modify for the middle ground, but I think setting up profiles is the wrong way to go. The only corollary to this is that it might make sense to set some values in a common config file, such a cloud provider, etc., but this shouldn't be hidden in a local profile.

Setting an interactive mode might be a nice user experience, add an issue if you agree and we can implement in a later PR

Agree, I'll add an issue 👍

[ivyleavedtoadflax]

Also bumping to 0.3.0 to cover new functionality.