get server address from a variable #190

New Issue

knoflook · 2021-06-22T10:23:15Z

knoflook commented

2021-06-22 10:23:15 +00:00

This is not a critical feature but it would be very convenient if you didn't have to type the full domain name(s) every time you want to do something on a server. Instead we could use a variable ($ABRA_HOSTS for instance) so if you are planning on runnning more than one command you can just export the hostname to this variable and voila you just saved yourself some typing.

decentral1se commented

2021-06-22 12:57:49 +00:00

Nice, yep. Flying by but we do have some completion stuff for this:

https://git.autonomic.zone/coop-cloud/abra/src/branch/main/completion

I don't personally use it as I tried one time and then rage quit trying to set it up but a lot of good work has been done by @3wordchant so I really want to try it again.

Been thinking about this a bit lately...

Nice, yep. Flying by but we do have some completion stuff for this: > https://git.autonomic.zone/coop-cloud/abra/src/branch/main/completion I don't personally use it as I tried one time and then rage quit trying to set it up but a lot of good work has been done by @3wordchant so I really want to try it again. Been thinking about this a bit lately...

3wordchant commented

2021-06-22 13:52:24 +00:00

Yep @knoflook I use the completion; abra a<TAB> bu<TAB> gives me abra app butt_autonomic_zone.

To do that, I have source /path/to/abra/completion/abra.bash in my ~/.bashrc.

ZSH completion was also working for me last time I tried it, not for @decentral1se though, yeah 😢

Back on the idea in this ticket – currently we're using docopt.sh for our command-line arguments, and I feel like making <app> optional for all the commands might be kinda confusing.. but maybe it's worth it for the convenience of that feature? Or maybe there's another way to handle subcommand-parsing?

Yep @knoflook I use the completion; `abra a<TAB> bu<TAB>` gives me `abra app butt_autonomic_zone`. To do that, I have `source /path/to/abra/completion/abra.bash` in my `~/.bashrc`. ZSH completion was also working for me last time I tried it, not for @decentral1se though, yeah 😢 Back on the idea in this ticket – currently we're using `docopt.sh` for our command-line arguments, and I feel like making `<app>` optional for all the commands might be kinda confusing.. but maybe it's worth it for the convenience of that feature? Or maybe there's another way to handle subcommand-parsing?

knoflook commented

2021-06-22 13:57:59 +00:00

Easiest thing I can think of would be to check the contents of said variable when the command lacks the <app> argument. Then we can just put this info in the help section and not change a lot.

Easiest thing I can think of would be to check the contents of said variable when the command lacks the `<app>` argument. Then we can just put this info in the help section and not change a lot.

3wordchant commented

2021-06-22 14:04:54 +00:00

@knoflook if you don't provide the <app> argument currently then it'll just show the help message:

$ abra app config
Usage:
  abra [options] a...

This behaviour comes from docopt.sh, so if we wanted to make <app> optional, we'd need to edit the docstring, e.g. changing:

abra [options] app <app> config

to

abra [options] app [<app>] config

or adding another line like:

abra [options] app config

I'd be down if anyone wanted to try that out, I'd be a bit nervous about collisions between commands, because the way we map subcommands to functions is tremendously hairy and fragile, but maybe it's fine!

Alternatively, we could maybe support - or ENV or something as a special <app> value, which means "read it from env var". I don't think I've ever seen an app do this, so I'm not sure what conventions, if any, exist for the naming 🤔

@knoflook if you don't provide the `<app>` argument currently then it'll just show the help message: ``` $ abra app config Usage: abra [options] a... ``` This behaviour comes from `docopt.sh`, so if we wanted to make `<app>` optional, we'd need to [edit the docstring](https://git.autonomic.zone/coop-cloud/abra/src/branch/main/abra#L15), e.g. changing: `abra [options] app <app> config` to `abra [options] app [<app>] config` or adding another line like: `abra [options] app config` I'd be down if anyone wanted to try that out, I'd be a bit nervous about collisions between commands, because [the way we map subcommands to functions is tremendously hairy and fragile](https://git.autonomic.zone/coop-cloud/abra/src/branch/main/abra#L2586-L2625), but maybe it's fine! Alternatively, we could maybe support `-` or `ENV` or something as a special `<app>` value, which means "read it from env var". I don't think I've ever seen an app do this, so I'm not sure what conventions, if any, exist for the naming 🤔

decentral1se added the

enhancement

question

labels 2021-07-04 19:55:30 +00:00

This repo is archived. You cannot comment on issues.