We have recurrent request for third-party software developers to use docker/compose as a go dependency, embedding Compose in their own application. Docker Compose was not initially designed with this use-case in mind.

This epic captures work to complete to actually support such an usage, which implies API stability and well defined boundaries between exposed APIs and internal implementation details subject to changes

• [ ] Refine requirements for composeService regarding command.Cli - we only need a subset
• remove use of docker/cli/streams which is highly specific to docker/cli integration Make progress Writer a CLI component #13316
• Move any "implementation details" subject to changes, into internal package
• Refactor RunWithStatus so that Writer mode is part of the API, not a global variable Make progress Writer a CLI component #13316
• Move progress package to cmd as a command line component Move progress package to cmd as a command line component #13357
• Move prompt package to cmd as a command line component introduce WithPrompt to configure compose backend to use a plugable UI component for user interaction #13308
• Make maxConcurrency and DryRun configuration options Setup Compose service using functional parameters #13312
• Replace AssumeYes option by an "always ok" Prompt implementation add AlwaysOkPrompt to replace 'AlwaysYes' current implementation' #13336
• Document use of docker/compose as a library SDK docs #13350
• Add LoadProject to SDK definition Add load project to api definition #13329