@rafaelfranca shipped an initial devcontainers feature which is awesome. Thank you!
I tested out and hit some slight hiccups. Mainly the devcontainers Dockerfile does not install all os dependencies depending on what rails app generator options you provide.
I was going to create a patch for the dev container Dockerfile but thought maybe it would be better to use the existing Dockerfile. This is how I have implemented it in the past and it does simplify keeping parity between environments.
No. It should not use the production Dockerfile. Development environments have different requirements. For example, you would not want to install GitHub CLI in the production container, but you would want to install in the development environment.
Now to the actual problem you had, which are the OS packages that are missing there? Iām asking because I want to make sure it is covered.
And now to myl vision of devcontainers, I donāt want users to be worried about Dockerfile to setup their development environment. Of course, that file is there if people want to change, but devcontainer has the concept of features, and that is what I think we should be using.
The current Dockerfile is limited by design. It is mostly a prof of concept that Iām planning to evolve before the final release. In the final release, I donāt want to have those lines on the Dockefile. Instead of that I want to have feature that the framework can compose, can update and people donāt need to deal with Dockerfile diffs every time Rails requirements change.
We are now working in our own features and images to simplify the devcontainer setup, so this will likely change very soon.
Thanks for taking the time to respond to my question! I figured the current Dockerfile for the devcontainer was more of a proof of concept but thought it still couldnāt hurt to pose the question earlier rather than later.
No. It should not use the production Dockerfile. Development environments have different requirements. For example, you would not want to install GitHub CLI in the production container, but you would want to install in the development environment.
I understand that many projects may want OS dependencies to exist in a development environment but there is no reason you cannot just add another target to the Dockerfile to cover this (I can put together a minimum example).
The composability idea is cool but that still doesnāt diminish the benefits of basing it off the same image all the necessary runtime and build tools would be guaranteed to be the same. You could then use the composability through devcontainers for the dev only tooling if that proves easier to compose.
As for the plugins. The issue for me was libpq-dev (for Postgresql). But I also booted the container and tested one of the other optional installed dependencies (bun) to see if it was available and it was not.
I have made a branch to help articulate my thoughts on how it could work. I pointed at my forks main so it does not send notifications to anyone on the rails team.
Did you consider making something like Dockerfile.dev instead of devcontainers? I may be wrong, but I think devcontainers can only really be used in VS Code, right? So other editor-using developers would need to interact with it via CLI, which I donāt think there really is?