Gabor asked in Slack about how people contributing to Drupal manage multiple different Drupal versions, and different contributed module branches, when using AI agents:
Anyone working with multiple core branches and multiple contrib modules being conntributed to with LLMs? How do you make sure stuff works? If I have one core checkout with contribs, cheaper LLMs always confuse the contribs are not in the same git repo. When switching between core branches (backports for 11.x and main), the testing setup is regularly broken, especially selenium. Ideally I would not have a bazilllion ddev projects for each branch but this way having a reasonable environment to work in with local testing is very hard. Often I resort to committing stuff and waiting for CI results, but then fishing out the test fails and fixing locally is a pain and also not fair to d.o and to issue followers
... and I thought, hey, this is a great reason to use Drupal Flake for development, along with the directory organization I've been playing around with as "Argo".
What is Drupal Flake?
Drupal Flake is a Nix-based environment for local Drupal development. I've been developing and using it for the past ~18 months or so, and this is the big problem it solves: providing a full running development environment using native binaries, no containers required.
It's an alternative to DDev, which the Drupal community has largely rallied around as the "standard" way to run Drupal locally. DDev is a great solution, and with a growing number of add-ons available to solve specific tasks, it's becoming even more useful and powerful.
But at the same time, we're seeing a huge proliferation of really great command line tools, TUIs, and AI agent frameworks, where the Docker containers DDev uses just get in the way. When you're using DDev, you need to either call individual commands (like drush, composer, phpunit, phpstan, etc) with "ddev" in front of it to enter the container for that command, or use `ddev ssh` to enter the container, where none of your shell tools are available.
Drupal Flake provides a nicer developer experience -- direct access to all your shell tools and the full running environment, with no container in the way -- both for you, and your AI coding agent.
Organizing your work for reusability
So Drupal Flake is part one of my solution here -- part two is organizing a directory hierarchy so your agents can inherit context. This is what I learned/discovered with the Argo project - you can provide instructions to agents in a parent directory that child projects can inherit. This means you can spin up a new project, and start a coding agent like Claude Code or OpenCode right there, and it can see the context from your parent project.
This is the pattern I'm using as I'm working on a collection of modules for integrating Matrix with Drupal. I also use it for testing issues I've been filing on contrib projects like ECA.
Fast, disposable Drupal environments
So: here's the demo. Before this video starts, I had Nix and Direnv installed. And my local environment has most of the Nix packages as well as composer packages cached -- if you are doing this from a cold start it will take a lot longer to download everything the first time. But this video shows every step needed to start in a brand new directory, install Drupal Flake, start up the environment, install Drupal, and log in, all in 133 seconds! And cleanup is even quicker -- all traces removed before the 3 minute mark:
Some notes:
- Nix flakes are the key technology this depends upon. Vanilla Nix still requires this to be enabled as an "experimental" feature -- the Determinate Systems installer does this for you by default, so that's the easiest way to get the prerequisites in place.
- Nix flakes have a couple strict rules about git - if you are in a git repository, then Nix will ignore any files that are not at least added to the git index -- this is why I used git add to add the directory, because my parent directory is managed in git. The git steps are unnecessary if you are not in a git clone - but if you are, they need to be added or else you'll get errors. (They do not need to be committed, git add is sufficient).
- Direnv is a convenience that is set up to automatically run `nix develop` when you change into a directory, as specified in a .envrc file. This is optional -- you can run `nix develop` yourself to enter the "dev shell" with PHP, NodeJS, and all the server software the Drupal Flake specifies available.
- The `setup-drupal` command is basically a wizard that creates a .env file, which needs to get added to git, and then the environment needs to get reloaded - this is the `direnv reload` command I ran, but you can also rerun `nix develop`.
- Drupal Flake uses process-compose to start up MariaDB, PHP-FPM, Nginx, etc using some info from the .env file. `start-detached` starts it all up in the background, `pc-stop` shuts down this instance.
- You can run multiple sites with Drupal Flake simultaneously, as long as they are on a different http port. The setup-drupal script generates a different port for different project names, so you shouldn't need to think about that unless there's a collision. `stop-all` will shut down all process-compose processes started by multiple Drupal Flakes.
- In the video, you can see my Starship prompt, which shows the PHP version active in the shell -- you can see it change from PHP 8.4 to 8.5 after I reload the environment. It also shows whether or not the flake is running, with the project name after a drop - flake icon.
Add new comment