feat: get completion for composer commands

[GuySartorelli]

Figured I'd get this done while autocompletion is on my brain.

The Issue

There's no autocompletion for composer commands right now, other than what cobra can give us.

How This PR Solves The Issue

If the cwd is inside a project with a running web container, we request completions from composer in the container.

This should work for all shells cobra supports autocompletion for - which is more than composer itself!

I've also added autocompletion for the create command (pretty much only useful for flags, but that's not nothing) and hidden the create-project command from completion suggestions.

Manual Testing Instructions

Running in any shell cobra supports for autocompletion, type ddev composer <tab>, and other combinations you'd expect to get autocompletions for (like ddev composer re<tab> to get completion suggestions for composer remove and composer require)

Also try out ddev composer create --<tab> to see completion suggestions for the create command.

Automated Testing Overview

Added a couple of small tests to check we do in fact get expected completions from composer. That test is pretty light because we don't need to actually test composer's auto completion suggestions - we just need to validate that we're passing the completion request through, and getting a correct response.

Related Issue Link(s)

N/A

Release/Deployment Notes

Should just work out of the box, no breaking changes, just nice auto complete goodness.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-linux-amd64.zip
• ddev-linux-arm64.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-windows-amd64-installer.zip

See Testing a PR

[rfay]

Although I'm a bash stalwart, there are an awful lot of zsh users out there, and it seems like most of them have oh-my-zsh.

[GuySartorelli]

I use ohmyzsh myself. Composer doesn't currently support autocompletion for zsh. There's a ohmyzsh plugin that provides composer completion - I'd say if zsh stans want completion for ddev composer before composer itself is resdy to provide them, a similar plugin probably needs to be created which is clearly outside the scope of this pr.

[GuySartorelli]

Upon reflection it occurred to me that cobra will handle making the completion results correct for a given shell - and indeed it does. So we can just tell composer we're using bash (just to get the completion suggestions) and then feed those to cobra, and cobra can feed them to our shell in the correct format.

Testing locally in zsh it works well. I don't have fish so I can't check that - but there's no reason to assume it won't work.

I'll update the PR description to match.

[GuySartorelli]

Note that I've made the adjustment as a separate commit so that this PR still contains a record of what the code looked like for finding the host shell. That might still come in handy some day.

[GuySartorelli]

And had one last epiphany. I said there'd be no container when running ddev composer create but that's just ridiculous - how would it run if there's no container? So I've added completion for that command now as well.

Note

I've also hidden ddev composer create-project so we're not including it in completion results - no need to encourage people to use it.
It'll still tell people to use create instead if people run it.
If you want this added back to the completion results let me know and I'll unhide it - but it really doesn't seem like it should be in completion suggestions.

Assuming CI goes green, this should be good to go now.

[GuySartorelli]

I'm 90% sure DisableFlagParsing and FParseErrWhitelist: cobra.FParseErrWhitelist{UnknownFlags: true} are functionally equivalent as far as running the command goes - but DisableFlagParsing is explicitly required for the completion function to be called. Not sure why, couldn't find any docs on it, but that's why I've made this particular change.

[GuySartorelli]

Changes in this file were automatically made by my IDE because in my first commit I had added some code there, then in the second commit I removed it again.
See #5756 (comment)

[rfay]

This seems great to me, manually tested and it did all the things. It can go in when the tests are green; currently TestComposerCreateAutocomplete fails.

[GuySartorelli]

Running make test TESTARGS="-run TestComposerCreateAutocomplete" I'm not able to reproduce the failure.
I don't know enough about the workflow setup to know what I could change locally to match the CI environment, which is normally what my next step would be here.

Could you please check if you can reproduce this locally, or give me some pointers about either how to reproduce it or what might be causing it to fail?

[rfay]

It succeeds for me as well. I ran the whole file's tests in Goland, with GOTEST_SHORT=12 (drupal10). The buildkite tests use GOTEST_SHORT=8 (drupal9)

But every single test failed, so the assumption has to be crosstalk between tests, some state is not being cleaned up.

Try make test TESTARGS="-run TestComposer" to get all composer-related tests.

Or try running all the tests in the cmd directory with GOTEST_SHORT=12 make testcmd

BTW, if you're not doing this already, you'll want to be running tests in vscode, it does a great job of running individual tests, and of course you can debug through them.

You're awesome!

Could you please PM me with your contact info (any way you want, Discord might be easiest?) I'd like to set up a meeting soon.

[rfay]

make testcmd demonstrates it, https://gist.github.com/rfay/967350ffd1038cb2f2db7902f2cdf1b5

The tests run in this order result in the failure:

=== RUN   TestCmdVersion
=== RUN   TestCustomCommands
=== RUN   TestLaunchCommand
=== RUN   TestMysqlCommand
=== RUN   TestPsqlCommand
=== RUN   TestNpmYarnCommands
=== RUN   TestComposerCreateCmd
=== RUN   TestComposerCreateAutocomplete
=== RUN   TestComposerCmdCreateConfigInstall

[rfay]

Oh look, isn't this the same thing happening here? https://github.com/ddev/ddev/actions/runs/7778487300/job/21208251886?pr=5058

That's in #5058 which was recently rebased to upstream/master.

However, upstream/master doesn't seem to be seeing this.

[GuySartorelli]

Try make test TESTARGS="-run TestComposer" to get all composer-related tests.
Or try running all the tests in the cmd directory with GOTEST_SHORT=12 make testcmd

Thanks! That worked, and I've adjusted the test accordingly. I was taking advantage of the site to test being started before my test run, but it seems that in some cases other tests will stop a site - so I need to make sure the sites are started before the test code is run. I've done this to both of the new autocompletion tests.

BTW, if you're not doing this already, you'll want to be running tests in vscode, it does a great job of running individual tests, and of course you can debug through them.

Thanks! I find with my workflow running tests in the terminal is preferable, though if I ever get a test that I need to debug properly I'll probably do that via vscode.

You're awesome!

Aww, shucks, thanks.

Could you please PM me with your contact info (any way you want, Discord might be easiest?) I'd like to set up a meeting soon.

I've flicked you an email.

[rfay]

Congratulations!

[GuySartorelli]

Looks like this is passing (just colima to go but with everything else passing I'd be shocked if that had a legitimate failure)

[rpkoller]

i've updated to the latest version of HEAD-edb09ef . but somehow i am unable to utilize the autocomplete. with the example from the manual testing instructions i get

for ddev composer <tab> and

actually no options at all to pick from for ddev composer create --. i am on macos sonoma 14.3 with zsh 5.9 (x86_64-apple-darwin23.0) out of the box in the terminal.

[rfay]

Is autocomplete in general working for you @rpkoller ? For example, does ddev l<tab> get you the things it should? I've been having funky problems with bash autocomplete in general. Are you using bash or zsh?

[rpkoller]

ddev l<tab> has no effect at all (*disclaimer but i haven't installed any autocomplete related with homebrew - i just tested because the issue summary stated it would work out of the box with nothing else required). And I am using the default for sonoma 14.3, zsh 5.9 (x86_64-apple-darwin23.0)

[rfay]

You have to install autocompletion or any of this to work. https://ddev.readthedocs.io/en/latest/users/install/shell-completion/

[rpkoller]

I use ohmyzsh myself. Composer doesn't currently support autocompletion for zsh. There's a ohmyzsh plugin that provides composer completion - I'd say if zsh stans want completion for ddev composer before composer itself is resdy to provide them, a similar plugin probably needs to be created which is clearly outside the scope of this pr.

on brief addition I did some digging trying to understand zsh completions and how to get them working for me (i've opened an issue about that #5803) and i've noticed that there actually is a completion for composer already available at /usr/share/zsh/5.9/functions/_composer (with Sonoma) . So in consequence autocompletion should work for composer commands if i understand things correctly?

[GuySartorelli]

i've noticed that there actually is a completion for composer already available at /usr/share/zsh/5.9/functions/_composer (with Sonoma) . So in consequence autocompletion should work for composer commands if i understand things correctly?

To the best of my knowledge, that will work for composer itself (i.e. composer <tab>) but not for the composer command in ddev (i.e. ddev composer <tab>)