Closed
Description
Currently libcnb-test runs various Docker related actions/commands using the bollard crate.
Whilst at first glance using a Rust client for Docker seems preferable, it actually has a number of disadvantages:
- Bollard's APIs mostly map to lower-level Docker daemon API primitives, meaning that what might otherwise be a single action using the Docker CLI instead requires the correct combination of multiple daemon API calls and associated edge case/error handling. This means we effectively have to reimplement parts of the Docker CLI, increasing effort of implementing any new feature and the chance of implementation error - which has already resulted in bugs: libcnb-test: Exit status of commands run via
run_shell_commandandshell_execare not checked #446. - The whole point of libcnb-test is that it's as representative as possible of how end users use CNBs and run the resultant images. End users don't run their containers using direct Docker daemon API calls, they use the Docker CLI. Plus, for maintainers of libcnb-test (or anyone debugging an issue with it), it's much harder to understand the codebase in terms of both Bollard+the Docker daemon API (particularly given their docs aren't great), given that we ourselves are really only used to the Docker CLI.
- Bollard has a very heavy dependency tree (partly due to requiring the tokio runtime) - for example, it increases the number of the Python CNB's transitive dependencies by 50%.