justafish / ddev-drupal-core-dev

ddev addon for core development
Apache License 2.0
24 stars 10 forks source link

fix: Install drush without affecting git index #33

Closed rfay closed 3 weeks ago

rfay commented 6 months ago

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

Testing:

Test with

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

Automated tests

Coming

simesy commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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

rfay commented 4 months ago

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

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 commented 3 weeks ago

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.