Correct. After pointing out quite reasonable reservations about the other two approaches. One being far too slow and the second not exactly following best practices for how to isolate different versions of tools and services from each other.
I’d be happy to try ! Bring 'em on…
I can prepare a PR to add the
docker-compose.yml file to the repository. There are really only four versions to maintain: ruby, yarn, postgres, and redis. I’ll assume that you have the supported versions or version ranges of those tools noted somewhere in the repository, and so it will just be a matter of keeping
docker-compose.yml synchronized across major updates.
The biggest thing that would need support from your end would be the changes to
config/database.yml, although there is already precedence in those files for using environment variables to override certain database connection options.
Again—running everything in a container proved to be very, very slow on my machine. This way the core Discourse rails process runs natively. I’ve been using this for plugin development for the past 24 hours and it is much more responsive. Meaning that I actually got some work done .
IIRC Docker compose comes bundled with Docker. It’s not a hard tool to use:
docker-compose up when you start and and Control-C when you are done. You could easily add this to a script similar to
d/unicorn if you wanted.
Keep in mind that the alternative native install on macOS has users run a shell script that uses brew to install whatever current versions of postgres and redis happen to be available at the moment, and then also starts them for good measure where they’ll run in the background forever after I (immediately) forget about them or don’t even notice what the setup script did. So the alternative to Docker compose is remembering to both
brew services (start|stop) postgres and
brew services (start|stop) redis. To me that seems equivalent / worse than using