You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docker compose config (or docker-compose config) is a command that
"parse, resolve and render compose file in canonical format"
it resolves several things. For instance, it honors the COMPOSE_FILE envvar, supports the resolution of several files and also different file names like compose.yaml (which is the current recommendation in the spec ).
The text was updated successfully, but these errors were encountered:
This is a very good point. Currently, docker-compose-viz doesn't rely on docker-compose being installed, and I was planning on keeping it this way. But I could see an interest here. I need to think a bit about this (or if you have any suggestion, PR proposal, etc. I am all ears).
I don't think there should be anyone who is trying to make diagrams based on the definition of one or more compose files and still doesn't have compose installed. Maybe the only exception is to avoid a dependency for example when you want to automate diagrams in your documentation (integrating with my sphinx extension for example), but it is a very corner case (for instance github action's ubuntu has docker and compose already installed).
Relying on a normalized result from compose config could simplify the implementation o this software a lot. Instead of supporting a certain value like list or map, you should only support the canonical format and you can ignore the other form. In short, I feel that you are basically making an alternative normalization parser that you will have to maintain forever.
On the other hand, It's would be trivial for me as a user to use config and "pipe" to the viz generator.
docker compose config
(ordocker-compose config
) is a command that"parse, resolve and render compose file in canonical format"
it resolves several things. For instance, it honors the
COMPOSE_FILE
envvar, supports the resolution of several files and also different file names likecompose.yaml
(which is the current recommendation in the spec ).The text was updated successfully, but these errors were encountered: