|
|
|
|
|
|
by capableweb
1001 days ago
|
|
|
> 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? |
|
|
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.