Is this project dead or stalled? Status?

[Enrico204]

Hello maintainers ( @muayyad-alsadi I think, maybe others?),

Unfortunately I see lists of issues and pull requests growing, with some interesting things (such as build-args, etc) that are still waiting, some even with 1 line fix waiting for 6 months or more (without being closed or accepted). This is sad, because this project can really be a good companion for podman.

What I'm asking is: there is any plan on the long run, or this project is dead? Or "temporary stalled"?

[muayyad-alsadi]

I'm just overloaded. Every weekend I say I'll work on it and get distracted.

I'll try to see what I can do tomorrow.

[rhatdan]

Hopefully others could help @muayyad-alsadi on this. Perhaps more contributors and reviewers. Sadly I know little of compose.

[harsh183]

It's definitely an interesting project and one I want to see become bigger. I'm up for donating a little. Earlier I was having issues with setting up killbill based off here which worked on docker compose but not podman compose.

[Enrico204]

I can help, I use docker-compose a lot and I know python :-) And I have some free weekends :-)

[muayyad-alsadi]

@harsh183 the reason why it does not work because

• killbill/killbill:0.22.2
• killbill/kaui:2.0.1

both listen on 8080 which is not possiblein rootless podman because the only way for container-to-container communication is to share network namespace and let them talk via. localhost

if there is some env variable you could pass to kaui to make it listen to 9090, then pass it and edit compose.yml to reflect that.

@rhatdan can't slirp4netns solve this in their newer versions?

[OneCricketeer]

Hey all!

Any chance y'all are aligned on Compose's upstream efforts to perform a Go rewrite?

Linking to https://github.com/compose-spec/compose-spec/issues/57

[Enrico204]

I'm a Go fan, I'll be happy to contribute to the rewrite :-D

[OneCricketeer]

@Enrico204 - https://github.com/compose-spec/compose-go

[yajo]

If podman is getting an HTTP API and docker-compose can use it, does this project make sense now? 🤔

[muayyad-alsadi]

Podman is daemon-less.

[Enrico204]

@muayyad-alsadi That's not entirely true: $ podman system service --timeout 5000 exposes the new REST APIs launching a daemon, which are Docker-compatible (AFAIK).

@Yajo yes, thanks, TIL. I didn't know about the new API service. I think that we don't need a clone of docker-compose now that it seems that we can link that tool to podman directly. I'll give it a try :+1:

[yajo]

Well it's not gonna work right now, currently it's experimental and has no networks endpoints. But I guess it should work for podman 2.0+

[ghost]

FYI the Podman apiv2 aims to be compatible with the docker API https://podman.io/blogs/2020/01/17/podman-new-api.html

Appreciate if we could get an "official" position from https://github.com/containers on the future of podman-compose. Will it be rewritten since now we have a spec and a compatible API https://github.com/containers/podman-compose/issues/126#issuecomment-610611390? Even better, will/could it be integrated https://github.com/docker/compose/issues/7292?

[rhatdan]

github.com/containers administrators has no opinion on this. We fully support all OpenSource projects on github.com/containers. podman-compose seems to have an active community and the Podman team values it's existence. Whether or not traditional docker/compose works well against the new Podman APIV2, remains to be seen.

We would also love to see how people look at using something like podman-compose to work with Podman advanced features like working with Pods.

[muayyad-alsadi]

I would like to make it clear that the focus of this project is rootless daemon-less user-space containers which is a value that docker does not offer it has its own pros and cons rootless has its limitations specially container-to-container communication via slirp4netns where we compensate using some mappings/hacks.

since docker does not offer this feature, it does not handle those workarounds.

[pkarakal]

Is there any update on this issue? It seems like a good idea to have a compose tool for podman but it is very unstable right now. Is there any roadmap for this project (even an unofficial one) ?

[rhatdan]

There are many PRs and commits going on in this project, so I would not say it is dead. As far as your particular issue, it might be that no one has had a chance to look at it, or wants to work on it. Opening up a PR to attempt to fix it, might be the next step for you, if you think you can.

[pkarakal]

The reason I am asking is that I see all these PRs piling up but don't see any review or attention from the maintainers. Also the latest release from a few months ago. I would be up to contributing to this project (but I don't know much about how compose works on the inside )

[awerlang]

I would like to make it clear that the focus of this project is rootless daemon-less user-space containers

To achieve this vision I think it needs to follow docker-compose to the extent possible. It's important for rootless containers adoption. I'll suggest setting up a project/board on GitHub. Add collaborators to review and merge PRs. Organizing a video call with interested parties to set priorities and figure out road blocks.

Shall we do it?

[shanemcd]

Any chance we can get a new release on PyPi anytime soon? The last release was ~15 months ago.

[ssbarnea]

To be honest, as a python developer, when I see instructions from https://fedoramagazine.org/manage-containers-with-podman-compose/ I am ready to start running and screeming, installing from development branch should never be advised.

I think our priority should be now to make at least a pypi pre-release and assure we update it, without pypi releases we cannot really claim that the project is usable for any practical purposes.

[rhatdan]

In another chain, we are talking about getting new maintainers, of this project, if we have volunteers who want to support it.

[ssbarnea]

If I would not already be overloaded I would sign up to help, hopefully situation will change for the better.

[pkarakal]

now that podman can be used as a backed for docker-compose (ref: https://www.redhat.com/sysadmin/podman-docker-compose) why would one use podman-compose instead of docker-compose and what are its pros (except for rootless containers which it doesn't support yet) ?

Also shouldn't one of the first steps be checking if podman-compose is complaint with the compose spec?

[rhatdan]

The question would be if podman-compose started to extend the compose spec for handling of Pods and advanced Podman features.

[thomas-mc-work]

Regarding official docker-compose support of podman: For me on a Debian machine it was required to provide the socket on an expected path:

ln -s /var/run/podman/podman.sock /var/run/docker.sock

The article is talking about a podman-docker package, which couldn't be found anywhere.

[yajo]

it was required to provide the socket on an expected path

You can export DOCKER_HOST and tell docker-compose to use another socket. See https://docs.docker.com/compose/reference/envvars/#docker_host.

[thomas-mc-work]

I think your way should be the preferred one. Here is the full instruction:

# cat /etc/environment
DOCKER_HOST=unix:///var/run/podman/podman.sock