Would command-chaining be desirable?

ilaflott commented 2 months ago

Currently, if one has a yaml or xml that defines a workflow they'd like to run with specific target and platform arguments, the commands at the terminal currently look like:

$] fre pp validate -e EXP_NAME -p PLATFORM -t TARGET
$] fre pp install -e EXP_NAME -p PLATFORM -t TARGET
$] fre pp run -e EXP_NAME -p PLATFORM -t TARGET

this is not disagreeable... but it is a tad repetitive- none of the arguments change. I suspect we will have many use cases where the arguments between steps simply don't change.

In this case, it might be nice to get another syntax in there, perhaps a list?

$] fre pp [validate, install, run] -e EXP_NAME -p PLATFORM -t TARGET

And, if it were to error at one of the steps, the error message should clearly identify which step failed, e.g. if install failed in a given case, we'd have something like

$] fre pp [validate, install, run] -e EXP_NAME -p PLATFORM -t TARGET
...
...
< error output >
...
...
ERROR: fre pp install failed with exit status FOO

cwhitlock-NOAA commented 2 months ago

Hi Ian - I think that this is what I'm working on with regards to the wrapper script, with a few differences:

The wrapper script currently includes checking on job status and there's no option to toggle that step off - you can't just run the validate, install, run steps; you also need to include a watcher that checks on how your job is doing. I can add a toggle for that option.
Because the watcher script covers more tools it takes options besides -e -p t - in particular, the checkout option allows for branch specification. However, the non-e,-p,-t arguments all have default args that allow a user to run specifying nothing but -e,-p,-t

On Fri, Jun 21, 2024 at 2:08 PM Ian @.***> wrote:

Currently, if one has a yaml or xml that defines a workflow they'd like to run with specific target and platform arguments, the commands at the terminal currently look like:

$] fre pp validate -e EXP_NAME -p PLATFORM -t TARGET $] fre pp install -e EXP_NAME -p PLATFORM -t TARGET $] fre pp run -e EXP_NAME -p PLATFORM -t TARGET

this is not disagreeable... but it is a tad repetitive- none of the arguments change. I suspect we will have many use cases where the arguments between steps simply don't change.

In this case, it might be nice to get another syntax in there, perhaps a list?

$] fre pp [validate, install, run] -e EXP_NAME -p PLATFORM -t TARGET

And, if it were to error at one of the steps, the error message should clearly identify which step failed, e.g. if install failed in a given case, we'd have something like

$] fre pp [validate, install, run] -e EXP_NAME -p PLATFORM -t TARGET ... ... < error output > ... ... ERROR: fre pp install failed with exit status FOO

— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/fre-cli/issues/108, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC362WXUAOKNSA7V4DJUR6TZIRTYHAVCNFSM6AAAAABJWQNFACVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3DOMBRHE2DCOI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Carolyn Whitlock

ilaflott commented 1 month ago

@cwhitlock-NOAA so i think here i'm really talking about something that could live within the wrapper script. Really what i think i'm getting at here is something like what click describes in 'advanced patterns'

so my prev command

# cli / shell
$] fre pp [validate, install, run] -e EXP_NAME -p PLATFORM -t TARGET

in click's python canon might look something like-

# python

## in fre.pp.validate
@cli.command()
@click.pass_context
def validate(ctx, experiment, platform, target, *other_info):
    ...
    ...
    if other_info.also_install:
        ctx.forward(install)
        ctx.invoke(install, experiment, platform, target)

## in fre.pp.install
@cli.command()
@click.pass_context
def install(ctx, experiment, platform, target, *other_info):
    ...
    ...
    if other_info.also_run:
        ctx.forward(run)
        ctx.invoke(run, experiment, platform, target)

## in fre.pp.run smth similar but no further forwards nor invocations
...
...

ilaflott commented 1 month ago

Closing- i leanrned more about @cwhitlock-NOAA 's wrapper- which does accomplish this.

from meeting, we agree the wrapper should probably have a new name though, to avoid confusion! 🤣

cwhitlock-NOAA commented 1 month ago

Any suggestions? I would welcome giving it a different one - but I'm not sure what a "bronx" equivalent would be for this project (for pretty obvious reasons I don't think I can call the tool "canopy").

On Fri, Aug 2, 2024 at 10:27 AM Ian @.***> wrote:

Closing- i leanrned more about @cwhitlock-NOAA https://github.com/cwhitlock-NOAA 's wrapper- which does accomplish this.

from meeting, we agree the wrapper should probably have a new name though, to avoid confusion! 🤣

— Reply to this email directly, view it on GitHub https://github.com/NOAA-GFDL/fre-cli/issues/108#issuecomment-2265517888, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC362WUITM34QWZ32GCJBXTZPOJNDAVCNFSM6AAAAABJWQNFACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRVGUYTOOBYHA . You are receiving this because you were mentioned.Message ID: @.***>

-- Carolyn Whitlock

ilaflott commented 1 month ago

Any suggestions? I would welcome giving it a different one - but I'm not sure what a "bronx" equivalent would be for this project (for pretty obvious reasons I don't think I can call the tool "canopy").

see #143 for continued discussion, FYI!

NOAA-GFDL / fre-cli

Would command-chaining be desirable? #108