docker.ubuntu should install Python packages only with consent from user

[gotgenes]

PR #92 introduced a number of helpful new options to install docker-py, docker-compose, and supporting Python packages. At the moment, these are all set to true, meaning that an unsuspecting user of docker.ubuntu will have pip, a new version of setuptools, docker-py, and docker-compose installed on her machine.

While most users will appreciate these tools, as a principle, it seems better to seek the user's consent, rather than install software the user may not need, especially without the user's awareness. In other words, follow the Principle of Least Surprise. docker.ubuntu seems to follow this philosophy for other items, for example, the linux-image-extras. So this brings the installation of Python-related tooling to be consistent with that philosophy.

I see a couple of inter-related issues here:

Avoid installing extra Python packages by default

All of the pip install settings in the defaults should change to false.

This also includes the installation of pip itself via apt installation of python-pip and python-dev. This action should happen with the user's consent. Document these options as a convenience provided by docker.ubuntu if they want to install the Docker-related tools.

Disallow contradicting settings

There exists a chance for contradiction in the settings, whereby, the user can specify true to install a tool like docker-compose, yet false for a dependency like pip. I see two solutions:

Implicit approval of dependencies

In this solution, explicit user-approval for a tool creates implicit user-approval of the tool's dependencies. Setting pip_install_docker_compose to true implies that pip must be available on the system. Similarly, setting pip_install_docker_py also implies that pip must be available. This dependency should be captured, and the need to install pip should be computed as a dependency, and installed if either setting is set to true (or both settings are set to true).

In this case, it seems best not to even expose an option on controlling the installation of pip, itself. Document the dependency, and that user consent to pip_install_docker_py/pip_install_docker_compose implies consent to install the necessary Python dependencies. Consider the case where the user sets pip_install_pip to true, but pip_install_docker_py and docker_compose both to false. This would cause docker.ubuntu to providing functionality unrelated to Docker (installing pip).

Explicit approval, error out with contradictory settings

In the second scenario, all the configuration values remain (but still set to false by default). When the user enters an incompatible combination, such as pip_install_pip: false and pip_install_docker_py: true, issue an error warning of contradictory settings.

I think this option will be more frustrating to the user.

Side-issue: Install pip using a role

There are a number of roles on Ansible Galaxy for installing pip; would it be possible to use one of those as a dependency? Alternatively, since this is a pretty small installation, at least consider turning the installation of pip into a first-party role inside docker.ubuntu. Then installation of docker-py and docker-compose can create a dependency on that role.

[lhoss]

@gotgenes could you do a PR to change this? Not sure what the maintainer @angstwad thinks but IMO a role should indeed try somewhat to keep new features disabled by default (also for downward compatibility). Just in this case, those changes are not that new anymore

[angstwad]

TBH, I'm of the opinion that by default, it should be assumed that this role will install the latest Docker toolchain which is the current default behavior. I'm not opposed to lookups happening to ascertain if Docker is already installed, and if so, prevents installation or upgrades without consent.

I'll take a PR to implement this behavior.

[angstwad]

This is two years old and installing these packages is now well-established; i find it increasingly unlikely we'll change the way deps are installed.