🇺🇸United States @rfay

As there hasn't been a commit to this project for 7 years, and you seem interested, I made you a maintainer of the project @jenlampton.

@samuel.mortenson, DDEV does it for Debian 12 Bookworm like this, which is very ugly: https://github.com/ddev/ddev/blob/a82397976cb06a440b23a81a474ceda13a428a...

Or build an Ubuntu 24.04 image and you can just apt install it.

Or you can use DDEV, which has been doing this for some time.

I don't know what `com.ddev.app-url` might have been used for, but I imagine it can be removed. It's not a required label (https://ddev.readthedocs.io/en/stable/users/extend/custom-compose-files/...)

In passing, note that the docker-compose.chromedriver.yaml there can only be used on AMD64 machines, so leaves out lots of local development environments. It would be better to remove that and refactor slightly to use `ddev add-on get https://github.com/ddev/ddev-selenium-standalone-chrome`

There shouldn't be a `~/.ddev/docker-composer.chromedriver.yaml` at all (that ~ means your home directory) but you may have a `.ddev/docker-compose.chromedriver.yaml` (not `docker-composer.chromedriver.yaml`).

There is also not a .ddev directory provided by this project. And there are no yaml files in this project.

So something about your setup is the problem.

I do find a reference to docker-compose.chromedriver.yaml in https://github.com/ddev/ddev-contrib/blob/41113f04f060177002de4a7b64086f... - you probably somehow had that obsolete recipe in your world somehow.

As it says there, "**The recommended approach for running tests that require ChromeDriver is to use [ddev-selenium-standalone-chrome add-on](https://github.com/ddev/ddev-selenium-standalone-chrome) instead.**"

Hi - DDEV maintainer here. I took a look, and there is no instance of DDEV_URL at this point in DDEV core, and there hasn't been for a year or two, but there used to be an instance of that in the GitHub Codespaces setup for DDEV.

I searched the entire DDEV org on github and didn't come up with anything. But I imagine you'll find out what's happening if you `grep -r DDEV_URL .ddev` in your project directory.

This was apparently a problem with Gitpod and was resolved in https://github.com/gitpod-io/gitpod/issues/20263 thanks to your effort, right?

Please close this if it can be closed now. Thanks for chasing that!

Just stopping by to say thanks for all your work on this!

Docker is complex, technical, and intimidating to set up, which I think makes it an inappropriate choice for the kind of end users we're targeting.

I don't think most DDEV users would agree, but I might be wrong. Most users set up OrbStack or Docker Desktop or Rancher Desktop in moments using the standard installers. There is no complexity any more than any other app they might install. DDEV users generally don't need to know anything at all about Docker, unless they start to get way out of the box. There are capabilities there, but I'll bet 95% of DDEV users don't add a custom Dockerfile or `docker-compose.*.yaml`

rfay → created an issue.

rfay → made their first commit to this issue’s fork.

Congratulations on getting this to RTBC!

rfay → made their first commit to this issue’s fork.

Rebased against examples 4.0.x

This was accepted and solved

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

@shaal and I rehashed this again on a call the other day. IMO this is really important. This has already been done for DDEV PRs and ddev-gitpod-launcher.

Thanks to @dalin for noting this and pursuing it. It does seem that this isn't a Drupalpod issue, or at least one that can be resolved in Drupalpod, so we need to be explicit about this for both new gitlab users and new Drupal.org users during the contribution workshops. @dalin has provided the exact steps to resolve.

rfay → created an issue.

@shaal this is a key problem when doing mentoring. Any thoughts about how to proceed with this?

I definitely wish this decision hadn't been made, but want to note that DDEV jumps through all these hoops for you for Drupal 11. It was not easy. DDEV uses the sqlite3 3.45 snapshots from snapshot.debian.org. I think for Ubuntu you might be able to use the snapshots from snapshot.ubuntu.com. But yes, this is a very inconvenient and difficult decision. Debian won't support 3.45 in stable until next year, and even then it will require update to full major version.

Kristen Pol → credited rfay → .

DDEV HEAD has PHP8.4.0alpha2 now, this should help with resolving the various issues. This will be updated and be in the next DDEV release, but is already available easily via HEAD, even using Homebrew. See https://ddev.readthedocs.io/en/stable/developers/building-contributing/#...

nicxvan → credited rfay → .

If you do this, please make sure to leave the `name` out of the `config.yaml`, so it can take the name of the directory it's in.

I would say try to include only the non-default lines of the `.ddev/config.yaml` and probably nothing else.

I'm not entirely sure this is needed, as

`ddev config --auto && ddev composer create drupal/recommended-project && ddev config --update` gets everything done right away. Or just `ddev config --auto` if composer install has already happened.

There are other projects that have moved to including the .ddev; it doesn't do much harm if the `name` is left out, but it does seem like it's a relatively inflexible approach, and it ends up having to be maintained in parallel with DDEV's changes. Not that things change much, but for example, if the default `php_version` changes (as it will this fall) or the `database` defaults change (as they have for D11) then the config has to be updated, whereas DDEV itself would have handled all that.

I demonstrate how to do this without changing composer.json in https://github.com/justafish/ddev-drupal-core-dev/pull/33 - that could be done anywhere. @joachim has more opinions about how to manage this problem. But it's not a very big lift to just install drush and then let git and composer.json forget that you did it.

nicxvan → credited rfay → .

nicxvan → credited rfay → .

nicxvan → credited rfay → .

ChrisDarke → credited rfay → .

Deleting the drupalpod/.git would be a step forward, but they still wouldn't know what to do next.

People don't read anything as you know, but adding more instructions is still OK.

Is there a way to change the default directory? That would also solve it, if we put them in the repos/* directory to start.

Thanks for opening this issue @dalin - All of us helped people who had this class of problem at the mentored contribution at Drupalcon Portland 2024.

I helped quite a few people with this confusion at the Mentored Contribution. They opened drupalpod and ended up in the drupalpod git repo (which is irrelevant to them) and didn't know what to do next. They were fine when I got them into repos/ but not fine before that.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

rfay → created an issue.

FYI for Drupal 11 only, DDEV will pull the Debian Trixie Sqlite3 package in v1.23.1, see https://github.com/ddev/ddev/pull/6137

I do think the 3.45 requirement will cause a lot of pain for the next year while operating systems catch up. People who are deployed on any stable distro other than Ubuntu 24.04 will find pain.

But as we all know... it's not used mostly except for testing. At least I think the installation and dburl are the only places you get complaints?

rfay → created an issue.

rfay → made their first commit to this issue’s fork.

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to hidden.

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to active.

rfay → changed the visibility of the branch 3443863-test-ignore-this-rfay to hidden.

rfay → made their first commit to this issue’s fork.

Just a note here about SQLite 3.45 compatibility. The OP says

> Debian and Ubuntu both have releases scheduled prior to Drupal 11's earliest release date which will support SQLite 3.45.

But that's definitely not true. Debian's next release (13 Trixie) is more than a year away, and current Debian 12 Bookworm has sqlite3 version 3.40.1. Trixie will in fact have 3.45 or later, but it's most likely Summer 2025. See https://en.wikipedia.org/wiki/Debian_version_history

(Ubuntu 24.04 does in fact have sqlite3 3.45.1)

This is a bit of a struggle for DDEV, because the ddev-webserver in v1.23.0 just upgraded to Debian 12 Bookworm, and likely won't get to Trixie for more than a year (certainly it will be after Trixie is released). It's never a stability-builder to mix packages from different distro versions, so I'm reluctant to put 3.45 in ddev-webserver by default, at least using the mixed-debian-version technique.

* DDEV issue: https://github.com/ddev/ddev/issues/6110
* ddev-drupal-core-dev workaround: https://github.com/justafish/ddev-drupal-core-dev/pull/23#discussion_r15...
*joachim-n/drupal-core-development-project - also pending

shaal → credited rfay → .

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

From DDEV maintainer: I note that TYPO3 adopted DDEV as official local dev years ago, and Craft CMS and Ibexa more recently. In all cases it has made so many things so much clearer for those organizations, and their docs just show you what to do, not assuming vast amounts of alternative knowledge.

Both TYPO3 and Craft have DDEV instructions embedded right into all their docs, so the path is clear and unambigous. They don't dodge the fact that there's more than one way to do it, but it doesn't require guesswork. They just tell you "here's how you do it with DDEV". Being unambiguous about a way to do things is not a sin. And as you see in these cases, DDEV is not offered as an exclusive choice, just as an easy and straightforward one.

TYPO3 installation instructions:

Craft CMS Installation instructions:

Craft CMS plugin installation:

The DDEV community has always considered Drupal a special friend and would love to support it more "officially", and it would make usage by newcomers ever-so-much easier.

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

volkswagenchick → credited rfay → .

DDEV HEAD now has PHP 8.3 support; you can already use it with `brew install --HEAD ddev/ddev/ddev` or other ways, https://ddev.readthedocs.io/en/latest/developers/building-contributing/#...

It will be in v1.22.2 before terribly long.

Not all extensions are there yet, as they're not in the upstream deb.sury.org packaging. So xdebug is still missing, for example.

Totally agreed @longwave, but the flip side is the entire ecosystem has become dependent on Umami because it's so great for demo environments. We all use it like crazy for everything. Maybe it's so very good that it should be promoted from experimental. Obviously it's not for production, but that doesn't mean it's not as valuable as something that should be for production.

Thanks, so glad to understand this better! I'm sure the ddev-drupal9-solr instructions can be improved as well because I've seen this a number of times when testing.