Open frenata opened 6 years ago
This is a great consideration!
We are already loosely coupling our code with the docker CLI API, so the question is do you think the golang docker API is more likely to change with higher frequency than the docker CLI API? My unsubstantiated guess is that the CLI and golang APIs will likely change in tandem (approximately at least) so it might be more efficient and clean to just choose the golang API.
That's a good point that the various APIs probably move somewhat in tandem.
Maybe? encouraging info from the docs:
The Docker daemon and client do not necessarily need to be the same version at all times. However, keep the following in mind.
- If the daemon is newer than the client, the client does not know about new features or deprecated API endpoints in the daemon.
- If the client is newer than the daemon, the client can request API endpoints that the daemon does not know about.
@frenata i've been working with the Docker golang API in another project and I'm p familiar with who it works etc. now, I totally wouldn't mind taking on a small refactor to leverage this API instead of using os.Exec
!
If this sounds alright, I could make a feature branch and get to work on this :)
Sounds great, I think this will make the code "more complicated" but also better. Calling out to exec
definitely feels like cheating to me.
As it stands, the code is a pretty ugly hack translated near directly from the old node implementation:
(and later)
It seems strange to fall back to the OS and a bash script to communicate to another process written in the same language, which seems to provide a healthy API.
On the other hand, interacting directly with the docker API might constrain the environments in which compilebox can run, requiring some amount of coupling between the host's version of
docker
and the API target of compilebox.https://docs.docker.com/develop/sdk/examples/ may be useful reading as well.