GitHub was a bit too eager closing

Thx @thaJeztah !
#1183 is now merged, @ndeloof we can bump version and use "missing" here

I'm still confused by the --pull-policy=build option (even more so because it's in the compose-file itself);

build: Compose implementations SHOULD build the image. Compose implementations SHOULD rebuild the image if already present.

• docker-compose up --build is (currently) to trigger a build; the builder (if no changes) should then use its caching mechanism to determine if a rebuild is needed
• --pull-policy=always (note that currently docker (buildx) build only supports --pull (boolean)) would in case of a "build" also update images used for the build itself

Note that the combination of --build and "pulling" can be tricky (what comes first?);

• a service that builds an image (and has "just" rebuilt its image) would first overwrite the fresh (locally built) image, then the build would overwrite it again with a the new version
• having a pull-policy in the compose-file (in various situations) would now effectively "force" a user to also pass --pull-policy on the command-line to override the behavior (local development cycle) to prevent work being "un-done"

So I'm still quite uncomfortable with the pull policy being in the compose-file itself; this really feels like an option that should generally be passed on the commandline, as it's not declarative.

I'm still confused because it's in the compose-file itself

The compose spec actually defines an model, and attributes can be set by yaml or command line flags, depending the implementation. This is up to users to decide if they want to hard code some behaviour in the yaml file or repeat --pull option. Basically, many users rely on compose to make docker run commands shorter and not have to remember tons of flags.

Note that the combination of --build and "pulling" can be tricky (what comes first?);

this is what pull_policy has been designed for. pull_policy: build means image should be built from source, not pulled. Compose spec is not designed to follow buildx UX :D

Basically, many users rely on compose to make docker run commands shorter and not have to remember tons of flags.

I understand how it's used, but still think there's a separation between describing/declaring a "stack", and runtime options / options for a specific deploy (I recall some discussion on that in docker/compose#846)

Most of the deploy section is actually about runtime options. It's way too late to make compose file format a clean, abstract declarative model.
From a pure usability point of view, users have asked for a way to get compose up to build first of pull first (on disctinct issues) with reasonable usage scenarios. With this attribute we give them an opportunity to achieve this. Obviously flags allow to override for other usages.

closing this, will see later if we want to introduce this flag to compose command