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

docker compat: use hyphens to join container names #1080

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

mattp-
Copy link

@mattp- mattp- commented Nov 29, 2024

docker-compose uses - not _ to join container names to project. not a huge thing, but for services making assumptions based on this it can catch off guard, and is easy to make the same.

@mattp- mattp- force-pushed the main branch 5 times, most recently from 226c9d6 to e9a46ff Compare November 29, 2024 17:20
@p12tic
Copy link
Collaborator

p12tic commented Nov 29, 2024

Good catch.

I think we should make this configurable, like with network names. Otherwise people will upgrade podman-compose and break their existing deployments.

Documentation for compatibility of network names between podman-compose and docker-compose: https://github.com/containers/podman-compose/blob/main/docs/Extensions.md#compatibility-of-default-network-names-between-docker-compose-and-podman-compose

docker-compose uses - not _ to join container names to project.
not a huge thing, but for services making assumptions based on this
it can catch off guard, and is easy to make the same.

Signed-off-by: Matt Phillips <[email protected]>
@mattp-
Copy link
Author

mattp- commented Nov 29, 2024

@p12tic makes sense, i can definitely add that. is there an env var analogue for those switches ? if not I can add that too. in my use-case im dealing with tens-hundreds of compose.yml's wrapped in a single executor, so i would want to influence the behavior there with env var rather than update each yaml. thanks 👍

@p12tic
Copy link
Collaborator

p12tic commented Nov 29, 2024

I'm usually against this, because environment variables increase risk that environment setting will not be set for some invocation and then podman-compose will do bad things.

However I see your point. The project should be flexible enough to satisfy user requirements and I'm not the one to judge user risk, this is their responsibility. So let's do like you say.

Let's do environment variable plus compose setting. If both are present and have different values, podman-compose must throw an exception.

Could you also do the same for network names for consistency?

Thanks

@mattp-
Copy link
Author

mattp- commented Nov 29, 2024

Sure thing 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants