Create dashed aliases automatically

[svetlyak40wt]

Is it possible to create dashed aliases automatically?

Right now I've added this code to the end of the tasks file as a workaround:

    for item in locals().values():
        if hasattr(item, 'aliases'):
            item_name = item.__name__
            replaced = item_name.replace('_', '-')
            if replaced != item_name and replaced not in item.aliases:
                item.aliases += (replaced,)

But seems, it is a good candidate to be included into the invoke itself.

[bitprophet]

To clarify, you mean so that e.g.:

@task
def foo_my_bars():
    pass

is exposed on the CLI as:

$ inv foo_my_bars
# AND
$ inv foo-my-bars

?

If so, yes, I agree that'd be nice, and I actually thought we had issues open for this but I can't find them. Maybe because I'm conflating it with the existing automated underscores-to-dashes we do for task arguments - i.e. def foo(my_cool_arg): ends up generating --my-cool-arg - which is another reason to implement this, I suppose - consistency of a sort.

[svetlyak40wt]

Yes, this is what I mean. I'll be glad to implement a patch for this feature.

[bitprophet]

The more nontrivial task trees and names I write, the more I want this myself. Many, many instances of @task(name='the-thing-being-decorated') in some internal codebases! May take a stab at it sometime soon.

Shouldn't be too hard (famous last words.) Would be enabled by some config value and thus you'd put something like tasks: auto_dashed_names: true in invoke.yml or similar.

[bitprophet]

Actually, need to explicitly jot this down, there's a few ways it could be done:

• As requested by the OP, where it's a semi-hidden "alternate" method of invoking tasks; they might show up in --list as foo_my_bars, but the parser understands that foo-my-bars means the same thing.
• The approach I had assumed coming back to this, where task names on the CLI are canonically one format or the other, and the parser and --list are on the same page - it's either dashes or underscores, not both.

Plus/minus breakdown:

• The first approach means no need to opt in; also that users may use whichever style they prefer (choice.)
• The downside with that option is that it's easy to confuse users who wonder why e.g. their local support documentation says "call inv foo-my-bars" but inv --list only shows foo_my_bars. (Yes, this will happen - trust me.)
  • Having a canonical name thus unifies representation and invocation and reduces ambiguity/confusion. The site operator gets to choose which representation/style is "house style" and that's how tasks are displayed and invoked.
  • And when it's an option, users may override it in their personal config files, so choice is still arguably preserved.
• We could list both formats in --list, but that's also confusing ("are those the same tasks, or not??") not to mention noisy/messy.

So I think I'm still coming down on the side of "make it an explicit setting" and that's what I will implement for now, tho I am open to arguments as always.

[svetlyak40wt]

Most unix command-line tools accept long options as dashed, not underscored.

Why not make it the only way how they will be named in next "major" release of invoke?

[bitprophet]

Remember that we're discussing task names here, not options! Options have been forcibly dashed for quite a while now :) (so e.g. def mytask(some_long_opt) becomes --some-long-opt.)

Re: making the backwards incompatible change, I might, we'll see. I think just having it be consistent but configurable is nice, though, since in this case the task name thing is aesthetics/subjective. There isn't a real POSIX convention for "subcommand names" like there is for options/flags.

[svetlyak40wt]

Oh, sorry.

[bitprophet]

While implementing: realizing that we should probably apply the same transformation to collection names as well, for consistency's sake.

[bitprophet]

There's also some annoying practical bits to be considered / recorded:

• There are a bunch of areas this impacts: --list, --complete, --help, as well as parsing.
• At the moment things are split up by responsibility, meaning that most of the code surrounding tasks and collections (and thus their names) has no access to configuration data (aside from the mostly-irrelevant collection-level config stuff, where we only really care about the config data already loaded from config files.)
• We could effect this by going low-level and having tasks themselves change their name on instantiation, which would then 'bubble up' and avoid having to modify the parser, display, etc code. However, we'd then need to grant that lower level code access to the config system. Should be possible but feels somewhat gross.
  • Counterpoint: the more we configure things, the more all parts of the system will want access to the early loaded config, so it may eventually be unavoidable.
• We could instead effect it by staying high-level and performing a transformation in the parser and CLI modules, a blanket s/_/-/g, which avoids the above problem of transmitting config info down the stack.
  • However: this would also require the inverse transformation in a few spots, because the internals of Collection and Task only "speak" the underscored version of names.
  • It also just means the changes are spread more widely - parsing, display, help, completion, etc, as above - and thus it's more work anytime the behavior updates, and more fragile / more prone to missing spots and thus introducing bugs/inconsistencies.

I am leaning towards 'transmit Config downwards, then have the expected name format bubble upwards' as it enables a lot more stuff in the future & should be less code, which is a nice combination. Transformative mappings (the other option above) feel awkward to me.