i know

what i'm saying is that it doesn't make much sense to do the separation in this case

Um, from a 12 factor application perspective, it certainly does.

out of the listed tools : the following are "dead" (do not run 24/7): nodejs, php the following are not "dead" : mysql, phpmyadmin, and apache in the case where you go to start a dev env and think "I'm going to do php development", all those will be running anyways, I don't see why it would matter ?

this is not a prod environment

What about the cases of working on a codespace that is a monorepo? I've worked on applications that use kind, golang, python and typescript all together. I think the idiom of "one service per container" doesn't apply here. The docker docs need to catch-up to the devcontainers idiom.

How do you deploy those apps, when they are ready for production? I mean, what do they end up on?

well that choice is left to the person that does the deployment, and the prod env is usually very different than the dev one

> the prod env is usually very different than the dev one And that too is very much against both the ideology of Docker and 12 factor apps.

is your development macbook 1:1 to the prod env ?

I am also unfamiliar with 12 factor apps, can you tell me about it ?

If I develop in a docker container, it's as close as it can be to prod. Yes. https://12factor.net/

I would argue that what you are saying would be done in an e2e test in your CI/CD to follow the 12-factor app method

That way your developers can diverge slightly more from prod, and your e2e test can be as close as possible

Otherwise it becomes way to much of a pain to have 4-5 separate coder workspaces for each lang

i'd like to mention you can have multiple containers per workspace though

I think that still fits the spirit of "trying to keep it as close as possible"

That is true, good point

Often hard to keep them using the same volumes tho

but I still like to think it's easier to not have too much different containers because otherwise you have to wire them up and it's usually more work on the dev

I've not had to work in more than two different languages at a time, and even then, I'd want two different editors open with the two code bases, just to help with context switching. I can't imagine needing to switch between 4 or 5.

two editors is different than having multiple tools in the same workspace though

nothing prevents you from having two to three vscode instances in the same workspace

So, I'd like to ask again, how are the apps deployed? If, for instance, they are deployed to a VM, then I'd suggest also putting another VM together with the same exact services installed, and use Coder in that second VM to code with. "The tools" should already be there. If, however, you are using Docker, you should have a second Docker environment set up, with all of the services also already set up and then you code in a single container per app being developed. If you need to develop on 4 to 5 apps (in the same or different languages) at a time, to me, I'd say in general there is something wrong. But, that is just me thinking I want the app to work in an environment that is as close to production as can be. I definitely don't want to have some very difficult bug pop up in CI/CD, because of diverging environments. The whole premise of Coder to me is, remote development. And why even go to the lengths of having remote development, if not to put the dev environment in one that is exactly the same as production? In the world of Kubernetes, it's practically a must, because there is no way to effortless build a k8s cluster with all of the services available on a dev's laptop. I'll also digress and say, to each his own. If you don't run into issues with diverging environments, then that is great. I won't want to take the risk.

I think it all comes down to the setup and the way of thinking of each, I'm personally fine developing on a machine that is semi-close to prod as long as I know the code I produce will run on prod, it's just that ease-of-use takes over in some cases, if I was using GCP, I wouldn't deploy a VM per service, I apply the same logic to my Docker setup, I just treat docker as a runtime and I don't want to spend time having to wire my containers together if I can have a singular container

once again, this also depends on the complexity of the environment and in some cases it is important to separate services

yo

is the chocolatey/scoop situation sorted out ?

yeah this would be pretty cool. Today the update of coder binary on my managed device is painful. Choco would solve this for me