fix(up): allow entrypoint and command together, place --entrypoint before image

[Cyb3rDudu]

Compose files using entrypoint: ["/bin/bash","-c"] (or sh) plus a multi-line command: heredoc silently drop the command: part — the script never runs:

services:
  web:
    image: httpd:2.4
    entrypoint: ["/bin/bash", "-c"]
    command:
      - |
        sed -i "s|Listen 80|Listen 8080|" /usr/local/apache2/conf/httpd.conf
        exec httpd-foreground

Two bugs in ComposeUp.swift::configService:

1. entrypoint and command go through an else if, so setting both means command is dropped.
2. --entrypoint is appended after the image and gets every entrypoint element — but container run --entrypoint only takes one binary.

Fix pulls the translation into a static helper:

• First entrypoint element → --entrypoint <bin> (before the image)
• Rest of entrypoint + every command element → positional args after the image

Tests: 8 static cases for the helper covering all combinations (nil/empty/single/multi entrypoint × nil/command, including the bash-c heredoc shape from #77), plus one dynamic test that runs sh -c with a multi-line script and asserts the container is actually running afterward.

Fixes #77.

[Cyb3rDudu]

Hey @Mcrich23, friendly ping on this one. Let me know if you'd like any changes — happy to rebase or adjust the approach.

[Mcrich23]

Apologies. I have been crazy busy. Let me take a look at this!

[Mcrich23]

I unfortunately won't have time to test it for the next week or two, but will definitely get it merged after then.

I appreciate your patience.

[Cyb3rDudu]

No worries at all, and sorry for being a bit blunt with the ping. I don't want to come across as pushy — I just noticed you'd been reviewing and merging other PRs while mine sat untouched for a month, and honestly that was frustrating. Getting your personal email thanking me for my contributions, then seeing the PRs I'd put real effort into go completely ignored, felt contradictory.

The reason I'm here in the first place is that I think this project is uniquely positioned. Container-Compose is literally the name people will search for when they want docker-compose on Apple's container runtime — there's enormous potential here for it to become the go-to compose tool for the entire Apple container ecosystem. That's why I jumped in to fix real bugs I was hitting in production stacks, and why I've tried to keep every PR focused and well-described with tests.

But the single-reviewer bottleneck is a real problem. One person gatekeeping every merge, especially with school and other commitments, means contributors like me and others who've filed PRs just end up waiting indefinitely. That's hard to sustain — it kills motivation, and the project loses momentum it can't afford to lose.

I'm not saying this to attack you — I genuinely appreciate that you built this in the first place and that you took the time to email me personally. I'm saying it because I care about the project and want it to succeed. Have you considered adding a second reviewer or giving trusted contributors push access? That would unblock everything and let you focus on school without the PR backlog hanging over you.

Either way, I'll keep contributing — the bugs I'm fixing are ones I need fixed regardless. Just wanted to be upfront about where I'm coming from.

[Mcrich23]

I am so sorry that I have made you feel this way. I absolutely agree and even went as far to talk about this in a post on the discussions tab. Don't worry about being pushy or blunt with me, it helps. It's very easy to get pinged on a PR, push it through and move on without checking for others.

I also wanted to share that I totally see you as a potential for that second person, but with so many security issues going on in the world, I have been really cautious to extend the invitation and ask you. If this interests you, I would love to talk a bit more about it over email and then go from there.

Regardless, I haven't tried this PR, but It lgtm, I trust you and I trust that it works, so I have approved it and merged it.