Add shorter flags for options that are used often

[ijnek]

Having shorter flags would save a lot of time (even when compared to using autocompletion). packages-select and packages-up-to were just the two commands that I believe is used a fair bit.
If these changes are fine, we could look into adding ones for other commonly used flags.

Signed-off-by: Kenji Brameld kenjibrameld@gmail.com

[ijnek]

Does anyone have thoughts on this?

[christophebedard]

Since package selection flags apply to all of the main colcon verbs, this would potentially lead to collisions; see also colcon/colcon-mixin#32 (comment).

However, given that package selection flags are pretty important for colcon, and given that --packages-select and --packages-up-to are the main package selection flags, I personally think that they should probably be "given the right" to have shortcuts.

cc @cottsay @emersonknapp, since you commented on/authored that other PR

[emersonknapp]

Personally I think it's smart - I have a lot of colcon aliases because of the verbosity of common workflows. But I'm not a decision maker on colcon, so I can just lend my opinion

[ijnek]

It seems like colcon is missing a decision maker.. (fair enough). who would be appropriate to @ to get this proceeding?

[nuclearsandwich]

I'll express a nay vote for this PR.

Coming from the vim and mercurial heritage I've got, I really enjoy command interfaces where you only need to specify enough characters to uniquely identify the intended command. However, a major limitation of that style is that it places restrictions on the command vocabulary and forces you to either break compatibility or never add an command which conflicts with a previously acceptable shortened spelling.

Additionally, adding single letter flags doubles (at least) the amount of context someone needs to have in order to mentally process a colcon command. Shorter flags are often overloaded mnemonically ("does -s mean silent operation?") which further hurts readability.

It seems that most command line interfaces these days prefer longer option flags combined with robust completion/suggestion interfaces and I believe that colcon already supports this on most platforms.

Given colcon's design for extensibility I think that doubling the potential interface size by introducing short flags is probably going to create more usability problems than standardized short flags would resolve.

Designing your own shell functions and aliases to streamline common workflows also works and I believe there are some additional colcon extensions, colcon-alias and colcon-defaults to name a few, which can also help reduce the typing involved.

[ijnek]

Thanks @nuclearsandwich for your thoughts. All of the points you made are valid and explain the downsides of this move well.

One thing that I want to add (or disagree), is relying on auto-completion for a long command. When ssh'd into a remote machine, or when working on a slow machine like a rapsberry pi, auto-completion can be quite slow. That leaves the user with the option of typing the whole flag out (with chances of typos), or waiting a non-trivial amount of time for auto-completion to return the candidates (or sometimes hanging for so long that you start bashing Ctrl+C). That's when I'd prefer shorter flags.

Also, auto complete isn't enabled by default in colcon, so I don't think we should straight up assume most people have it enabled.

But again, I understand the points you raised and I'm happy to look for some better solution if one exists.

[nuclearsandwich]

One thing that I want to add (or disagree)

I think disagreement, or perhaps more precisely dissent, is entirely welcome especially when well explained. This question, like a lot of maintenance decisions which are largely preferential or in the pursuit of "sensible defaults" will probably be revisited periodically as new users experience similar friction and propose revisiting these decisions and while I am not encouraging anyone to spam us with requests for short args, there could come a time when implementing them becomes the best answer to the problem and having both the maintainer and dissenting positions well laid out helps us to quickly get up to speed on what has and hasn't changed since the last time a discussion was had.

Also, auto complete isn't enabled by default in colcon, so I don't think we should straight up assume most people have it enabled.

This is a valid point, those who are coming to colcon via the ROS 2 tutorials are encouraged to set up autocompletion but it's an easy to ignore step as nothing breaks if you don't do so. I've left some thoughts in the linked issue about how we could make setting up autocomplete slightly more user friendly but do to the architecture of autocompletion in most shells it is unlikely to ever be fully automatic.

That leaves the user with the option of typing the whole flag out (with chances of typos), or waiting a non-trivial amount of time for auto-completion to return the candidates (or sometimes hanging for so long that you start bashing Ctrl+C). That's when I'd prefer shorter flags.

I've tried to avoid mentioning this because at best it's a weird flex 💪🏼 and at worst it is me being very smug, but I don't have autocompletion enabled for anything but filenames and even then I try not to lean too hard on it (you only combine rm -rf and tab completion once...) so I do spend most of my time just typing out colcon commands verbosely and I don't feel like that's the part of my workflow that slows me down. However, I've invested a relatively sinister amount of time into touch typing and put energy into using an ergonomic keyboard so the difference between -s and --packages-select` is not really significant.

but (and this is the reason I bring up my weird flex above) I do think that there is another alternative for ergonomics beyond shortening flags and autocompletion which is user-customization.
When I'm iterating on a workspace doing frequent rebuilds or re-executions of the same commands I'll usually toss the command sequence into a local script (usually build.sh or run.sh and then just keep re-running that script rather than retyping commands. Several colcon extensions have features which assist with this by letting you define your own behavior. I mentioned colcon-alias and colcon-defaults previously but I could also think of some pretty devious ways to get colcon-mixin, which is part of the commonly installed extensions, to do some interesting workspace specific things. You can also forego wrapping colcon entirely and build out your own shell functions which wrap colcon features. When running bloom for every ROS 2 release by hand was a thing I did more often I had an entire host of shell functions to facilitate that.

I neglected to save them on an earlier workstation I had a shell function called bp (build packages) which invoked colcon with the usual set of flags for ROS 2 and with the bp arguments passed through to --packages-up-to. You can do lots of cool stuff with some shell functions and directory-specific / workspace-specific environment hooks like direnv.
The disadvantage there is that each of us are on our own, but I think that also frees folks to build the interfaces which abstract over the pieces they don't interact with and focuses on the bits they do. Maybe after the upcoming office hours](https://discourse.ros.org/t/open-robotics-infrastructure-community-office-hours-all-things-colcon-2022-09-26/27390/2) we should start a thread on discourse of everyone's favorite colcon workflows.

[ijnek]

Thanks @nuclearsandwich for your detailed thoughts, and others for your opinions.

I'm going to close this PR off as I don't see any ways to go about improving it, but I believe the discussion in this thread will serve as a good starting point for any future discussion about this!