completions: add "show-changelog" to slackpkg completion

[rworkman]

This is newly supported in slackpkg-15.0.x

Signed-off-by: Robby Workman rworkman@slackware.com

[akinomyoga]

Thank you for the patch! Have you noticed the following sentence in CONTRIBUTING.md?

For example, we generally do not want to hardcode lists of available command options and their completions, because they quite probably vary between versions of the completed command, and therefore resort to scraping --help output and the like.

If we would include the completion for version-dependent options, I think we want to check the version of the command. Can you update it to check the output of --help and conditionally add the new option? Or, if it is difficult, maybe you can extract the version and check that the version is 15.0.x or higher.

[rworkman]

I am slackpkg upstream maintainer also. Given how the Slackware ecosystem functions, there's little to no reasonable likelihood of a user having a bash-completion release new enough to support this new option and a slackpkg version that is not also new enough.

[akinomyoga]

I am slackpkg upstream maintainer also. Given how the Slackware ecosystem functions, there's little to no reasonable likelihood of a user having a bash-completion release new enough to support this new option and a slackpkg version that is not also new enough.

I'm not familiar with Slackware, but I don't see the logic. That seems to be true only when that bash-completion is under the control of the Slackware packaging system? In Slackware, is it discouraged to install the latest software in /usr/local or in a user directory such as ~/.local? It seems that Slackware 15.0 is still under the development, and previous versions are still used widely. What if we merge this PR today, and a user pulled the latest version of bash-completion from GitHub tomorrow?

Also, if you are a maintainer of slackpkg, could you consider including the completion script in slackpkg itself rather than having them in bash-completion? We generally recommend including the completion scripts in the upstream of the corresponding command. The details are described in CONTRIBUTING.md. We accept completions only when the upstream maintainers refused to include them in their package for some reasons. Is there any reason that we cannot include the completion script in slackpkg itself?

Edit: Fortunately, we share the license GPL v2, so I guess it shouldn't be a problem to migrate the completion script into slackpkg. If we need Signed-off-by: for the significant contributions to slackpkg, we may ping the original author, @GArik. He seems to be still active on GitHub.

[rworkman]

Building and installing to e.g. /usr/local is certainly supported, but it's not at all recommended for software that's packaged by the distribution (and bash-completion falls in that category). If a user installs bash-completion from github (instead of from the distribution package) tomorrow and something breaks, that's on the user and it's what we call a learning experience :-)
All that said, I think the better approach is to pull the completion file into slackpkg, on the condition that you folks are willing to hold my hand later if modifications are needed due to changes in upstream bash-completion :-)

[rworkman]

@GArik and @scop and you all have commits that touch the slackpkg completion file; how would you all like to see this imported into the slackpkg repo? I'm amenable to importing the initial file and walking through each of the changes since then if that would be preferred...
Here's a WIP branch (commit message gives credit to all of you), but I don't think it's obvious enough: https://github.com/rworkman/slackpkg/commits/shell-completions

[GArik]

Moving the completion to slackpkg is a great idea. Especially if you are going to maintain both the code and the bash completion :)

[GArik]

The only drawback I can think of is that moving tests to another project would be rather difficult.

[akinomyoga]

@rworkman @GArik Thank you for the update and comments!

@scop What do you think of moving completions/slackpkg to the upstream slackpkg repository?

I'm amenable to importing the initial file and walking through each of the changes since then if that would be preferred...

Hm, are you talking about reconstructing the commits by filter-branch --index-filter? I think we don't necessarily have to preserve the exact history, but it is certainly a possible option if you or another one would like it.

Here's a WIP branch (commit message gives credit to all of you), but I don't think it's obvious enough:

You may use Co-authored-by: Name <email@address> trailers at the end of the commit message so that GitHub recognizes the contributors to that commit.

The only drawback I can think of is that moving tests to another project would be rather difficult.

Yes, that is one problem. Currently, the test seems to check just that it produces at least one completion for -. In addition, it is checked that the completion function doesn't change the environment (including global shell variables, shell functions, and shell settings) while the candidate generation.

[scop]

I'm all for moving the file over to slackpkg, thanks! As said, the tests are the biggest "loss" in doing that, but IMO the benefits outweigh that. The branch looks good, added one cosmetic comment there.

I'll rename our slackpkg completion to _slackpkg and mark it as deprecated, that's a convention we employ to avoid clashes when completions become available upstream. I guess in this particular case we could consider even removing it from bash-completion rather quickly.

[rworkman]

slackpkg 15.0.4 is released, so it's safe to merge the deprecation ; thanks!

[scop]

Deprecation merged, thanks!