> I never understood the appeal of docker-compose (you can accomplish roughly the same thing by having a Shell script that calls docker client, but skipping the Python clown fiesta with dependencies, environments etc.)

Basically the appeal is "one command > everything running" when you have multiple services working together, which sure, you could do with imperative shellscripting, but for people who don't spend their daily time writing shellscripts, something declarative like YAML is usually easier to get started with, especially when you only revisit it sometimes.

Python people generally have either installed by default in their OS, or already using because of some other system. I wonder how many developers don't have Python at all on their systems already?

> Basically the appeal is "one command > everything running"

But I can accomplish this with Shell script... And no need to deal with Python, its broken dependency management, poor piping / I/O in general, bugs in the docker-compose itself... What do I win by having to suffer all these problems?

> who don't spend their daily time writing shellscripts,

Do you write docker-compose scripts daily? Seriously? Why? My impression was that you write that once and edit very infrequently (like maybe once a month or less). So, in terms of time investment it doesn't seem to make much of a difference. Also, I see no value in imperative vs declarative approaches here. It's actually hard to understand what is going to happen when you use declarative style because you need to rely on and have a very deep knowledge of the imperative aspect of the system interpreting your declarations to be confident of the end result.

> Python people generally have either installed by default in their OS,

Being one of "Python people" I have Python 3.7 thru 3.12 built from respective heads of cPython project installed on my work laptop. I would hate to have to add more to support a tool with dubious (or as is my case extraneous) functionality.

Also, being one of those "Python people" who deals with infra, I had to import docker-compose code into my code and deal with it as dependency, both with its CLI and its modules. And... it's not good code. Well, like the wast majority of Python is a piece of garbage. Particular feature of docker-compose that stands out is that it was written by "Go people" with poor command of Python, so it's "Go written in Python" kind of program.

Also, people who write docker-compose don't care about how it interacts with other packages, and this shows in how they define their dependencies (very selective versions of ubiquitous libraries, eg. requests) that will almost certainly not play well with other libraries you'd use in this context (eg. boto3). I had plenty of headache trying to use this tool and had so far sworn never to use it in my own infra projects because of its dependency issues. If I ever use it (as in to deal with someone else's problems) I install it in its own environment. Which is yet another problem with its use because then you'd have to switch environments just to call it, and then you forget to switch back and things start behaving weirdly.

> I never understood the appeal of docker-compose

Using a recent HN submission to spin up a local vector stack for analyzing notes, https://github.com/memgraph/odin/blob/main/docker-compose.ym...

How would you suggest a bash script handle configuring all the different images, their ports, and ensuring services are spun up in the correct dependency graph (parallel where possible), and are exposed to each other as a reliable host name over a subnet without polluting the host network?

And then how is that bash script extendable so it's not a custom script every time?

docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally). So your yearning for speed optimization is kind of misplaced. If you are using docker-compose, you probably don't care about speed anyways. And, the way I understand it's typically used is to create some slice of the system a developer is working on, so unless we are talking about many minutes difference, the speed gains are inconsequential. Also, because you are using it to deploy just the relevant part of the system, the setup won't be complicated -- it's counterproductive to do that in a completely local system and especially because you want to work with as few components as possible during such deployments.

So, how would I go about that in Shell? I don't see a problem. Can you point to a specific problem? All these settings in your example easily translate into docker commands.

> docker-compose is slow and not quite parallel (because it's written in Python and uses requests internally).

This hasn't been true for quite some time. Docker compose v2, written in Go, was released in 2020; v1 finally officially stopped receiving security updates this summer.

Shell scripts suck to write and bash/zsh is a terrible language to have to deal with

And so does Python. But Python is unnecessary for this task. So, having to choose between two evils, I'd choose the necessary one.

Idk what python you're talking about with docker compose

For real. Maybe he should try docker compose v2

Why? What do I stand to gain from using this? Marginal speed improvement in some cases and a lot of headache trying to debug it in other cases?

docker-compose offers an alternative. It doesn't offer any genuinely new functionality. It may work for you if you don't know how to use the other alternative, or the other alternative is inconvenient for you for some other reason, but if it's not, it's just an extra tool that you don't need.

This one: https://pypi.org/project/docker-compose/

That's v1, which is EOL. Docker compose v2, written in Go, was released in 2020.

Well, that's even worse in some sense... now I cannot properly debug it when it breaks...

I still see no reason to use it.

When putting multiple containers together docker-compose will handle setting up the networking and hostname lookup so that the services can communicate with static names and ports.

Among other things.

But I can do that with Shell too. Convenience may depend on how well you know either tool, but I claim that if Python is unnecessary for this task (and you cannot escape having a Shell), then why bother with Python? The gain, if any, seems not worth the trouble.