@doanac I wonder if we should call this dir compose_apps as well as the command line param as compose-apps, maybe leave it as docker* since docker term is more common (I am subjective here) or maybe docker-compose-apps?

I've been leaving "docker" out because:

• docker-compose-apps is a mouthful
• docker-apps and docker-compose-apps look really similar.

I almost wonder if we should call this cli argument "apps". Then the parameter is good either way.

Another thing I realized we need to check for: We should only enable this new logic if "DOCKER_COMPOSE_APP" is defined in the factory-config.yml.

I almost wonder if we should call this cli argument "apps".

+1, What about the configuration variables in sota.toml and the apps directory name?

We should only enable this new logic if "DOCKER_COMPOSE_APP" is defined in the factory-config.yml.

Do you mean taking into account it in the lmp-device-register recipe? I suppose a package manager type should be defined anyway. This is actually not a new logic just renaming.

@doanac let's chat and make a decision on this.

Do you mean taking into account it in the lmp-device-register recipe?

Correct. We'd need to set this in our lmp build logic around here:

https://github.com/foundriesio/ci-scripts/blob/master/lmp/bb-config.sh#L27

and then the recipe could key off that value if it exists.

What about the configuration variables in sota.toml and the apps directory name?

I don't have a strong opinion on the variable names. As per the "apps" directory. I noticed that on my local test device I had simply named the directory /var/sota/compose. I kind of like just calling it "compose" - once its on disk its just vanilla compose. Its only the transports that's doing something new.