Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rely on docker compose config command #9

Open
mgaitan opened this issue Apr 15, 2023 · 2 comments
Open

rely on docker compose config command #9

mgaitan opened this issue Apr 15, 2023 · 2 comments
Labels
needs-discussion Needs refinement or discussion before being implemented

Comments

@mgaitan
Copy link

mgaitan commented Apr 15, 2023

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 ).

@derlin
Copy link
Owner

derlin commented Apr 16, 2023

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).

@derlin derlin added the needs-discussion Needs refinement or discussion before being implemented label Apr 16, 2023
@mgaitan
Copy link
Author

mgaitan commented Apr 22, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-discussion Needs refinement or discussion before being implemented
Projects
None yet
Development

No branches or pull requests

2 participants