homeadditions per project type

[jenlampton]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your feature request related to a problem?

I would like all my type = drupal7 sites to contain registry_rebuild for drush, and all my type = backdrop projects to contain bee without needing to specifically add these things to each project individually.

Describe your solution

I just learned about homeadditions today, and I love this feature!

I then wondered if it might be possible to add a type-specific homeadditions so that when a container was created, it could look for:

• first, global homeadditions
• second, type specific homeadditions
• third, project specific homeadditions

Describe alternatives

Alternatives: global homeadditions as well as project-specific homeadditions

Additional context

Relevant conversation at the end of this older closed issue https://github.com/ddev/ddev/issues/953

[GuySartorelli]

How would this be implemented? I.e. where would you put the homeadditions files for a given project type?

[stasadev]

I think this can be done in a similar way as in the custom commands annotation ProjectTypes https://ddev.readthedocs.io/en/stable/users/extend/custom-commands/#projecttypes-annotation

[rfay]

I'd rather think about how we can make slight adaptations your workflow using the many available features of DDEV than suddenly break the people who have been using this feature for years.

According to (current) drush docs you can even use environment variables (which can be specified globally in DDEV) to do most things. I imagine you can specify whatever you want there, including different .drush directories for different project types.

Probably the best thing you could do would be to bring drush config into your project, so it's under source control in the drush directory.

And... even if you only used the technique described in https://github.com/ddev/ddev/issues/953#issuecomment-2292366413 it wouldn't do any harm if you had ~/.drush/registry_rebuild in projects that were not D7 or Backdrop would it?

We're very happy to advise on how to use features to accomplish goals. And new feature suggestions are great. But in general... we need to hold them back, just as you do with Backdrop, because every single feature requires resources to create, and generally adds confusion, and then requires permanent maintenance.

[jenlampton]

How would this be implemented? I.e. where would you put the homeadditions files for a given project type?

If global home additions are added in ~/.ddev/homeadditions, I was thinking something like ~/.ddev/drupa-7/homeadditions or ~/.ddev/type/drupal-7/homeadditions

I think this can be done in a similar way as in the custom commands annotation ProjectTypes ddev.readthedocs.io/en/stable/users/extend/custom-commands#projecttypes-annotation

I'll read up on this, thanks!

I'd rather think about how we can make slight adaptations your workflow using the many available features of DDEV than suddenly break the people who have been using this feature for years.

I would never suggest anything like that... I was recommending a third option that would only change things for people who chose to use it, and would not have any affect on any existing instance without opting-in specifically by adding additional configuration.

And... even if you only used the technique described in https://github.com/ddev/ddev/issues/953#issuecomment-2292366413 it wouldn't do any harm if you had ~/.drush/registry_rebuild in projects that were not D7 or Backdrop would it?

Nope, it wouldn't harm the project -- it only harms the developer who needs to add it manually every single time. My goal is not to improve (or even change) active projects, but to make set-up for new projects less painful. The solution mentioned in https://github.com/ddev/ddev/issues/953#issuecomment-2292366413 only works for a single project. What about the next 120 I need to set up?

We're very happy to advise on how to use features to accomplish goals.

I'm going to start with the custom commands annotation ProjectTypes and see if that will help :)

[chrisfromredfin]

Even though you can have a homeadditions per-project, you can also have a global ~/.ddev/homeadditions, which will apply to every ddev project on your system. That's why we were saying "it wouldn't hurt if it showed up on a Drupal 10 site." I think you're still thinking homeadditions is per-project only, but there's (1) per-project and (2) global. (And you're proposing (3) - per-project-TYPE). I just want to make sure you know that global functionality exists.

See: https://github.com/ddev/ddev/issues/2055 and: https://ddev.readthedocs.io/en/stable/users/extend/in-container-configuration/

DDEV looks for the homeadditions directory both in the global ~/.ddev/homeadditions directory and the project-level .ddev/homeadditions directory, and will copy their contents recursively into the in-container home directory during ddev start. Project homeadditions contents override the global homeadditions.

(I may be completely mistaken, though, and if so, I apologize in advance :) )

[rfay]

Global homeadditions sure seems like it solves @jenlampton 's problem. One time setup per computer. Never touch it again.

[jenlampton]

I will try global home additions, and not waste any more of your time unless I'm sure there's an unresolvable issue. Thank you both, I appreciate you taking the time to explain everything.

[GuySartorelli]

Just as a point of interest - the issue description does very clearly mention global homeadditions.

In most cases global homeadditions probably won't hurt the projects they're not intended for, but it is conceivable that there's scenarios (edge cases admittedly) where you want something for a project type that would be actively harmful to other project types. Just putting that out there.

[jenlampton]

The scenario I am imagining is that Drupal and Backdrop both use Drush, but Backdrop is limited to Drush version 8. So if you needed drush in your Drupal 10 projects as well as your Backdrop projects global homeadditions could be an issue. (Though Drupal 10 sites do usually bundle drush and drush config with the Drupal project, so maybe not?)

Many of us prefer to use bee for Backdrop but bee is still missing a handful of drush features. I could see it becoming an issue as Drush 8 and modern drush diverge, especially for Drupal 7 sites that are moving to Backdrop, and previously relied heavily on drush commands.

This is only a theoretical problem right now, though, so I'll return if/when I run into an actual issue. I expect there might already be work-arounds for each problem, but wtithout a specific problem to investigate there's nothing more I can ask atm :)