fix: Install drush without affecting git index

[rfay]

This PR installs drush (on demand) so it can be widely used. This is also a first step toward being able to install database types other than sqlite3

• Script install_drush.sh saves away current git index state, installs drush, then rolls back to original image state
• Custom "drush" command checks to see if drush is available, and if not, runs install_drush.sh

Testing:

Test with

ddev get https://github.com/rfay/ddev-drupal-core-dev/tarball/20240501_drush

• Start a project
• Use ddev drush st to see it get installed
• Then ddev drush sql-cli and ddev drush si -y demo_umami --account-pass=admin
• git status should show no changes of any kind.

Automated tests

Coming

[penyaskito]

As someone who uses the stash a lot I'm worried this might affect people workflows, so let's try to leave the stash list as it started.

[simesy]

I tested this and it works well.

I like that it clearly doesn't change the installation unless you run ddev drush.....

I was also keen see that it did not change the container or service definition of the application. I dumped $container_definition, service IDs and then compared these before and after and I could not see any difference between them, so my conclusion is that adding drush does not change the drupal application state.

[rfay]

Thanks for the review. This just introduces drush and makes it available. It doesn't change anything about the code. When we introduce the use of different database types and such we can explain how to use ddev drush more fully.

[rfay]

@justafish this has now been rebased and is passing tests and has tests for the drush usage. I think everybody will like it :) Hoping you can pull it, and we can move on to using other database types in

• feat: Allow installing and testing with all database types, including MariaDB #34

[rfay]

@justafish I'd love if you could take a look at this (and

• feat: Allow installing and testing with all database types, including MariaDB #34

I'm hoping to do some performance comparisons using tmpfs/memory-based database mounts (mariadb) and it will be easy and fun to do with these in.

[justafish]

Hi @rfay - thanks for this PR. This is a tricky one for me - I think when we initially discussed this it was to do it in a way that would put everything back to how it was before running the command. However, for me that includes the vendor directory otherwise I'm developing against an unknown set of dependencies. For me it's absolutely fine to have visible changes in composer.json/composer.lock when I've installed an outside dependency like this - I actively want to know that what I'm working on isn't the same anymore as there's no way to distinguish between this situation and when you're purposefully adding/upgrade/removing packages.

So closing this PR for now, but please do re-open if there's any ideas for creative solutions that don't break the workflow I described.