# Proposal: trimming down the Ansible community package and collection removal roadmap **URL:** \ **Category:** Project Discussions\ **Tags:** azure, windows, gcp, aws, community-wg, network, galaxy-ng, kubernetes\ **Created:** [October 30, 2026, 10:03am UTC](https://forum.ansible.com/t/proposal-trimming-down-the-ansible-community-package-and-collection-removal-roadmap/46563 "2026-10-30T10:03:41Z")\ **Posts on this page:** 1\ **Showing post:** 20
**Author:** ![bcoca](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/bcoca/32/9269_2.png) [@bcoca](https://forum.ansible.com/u/bcoca)\ **Post date:** [October 31, 2026, 3:44pm UTC](https://forum.ansible.com/t/proposal-trimming-down-the-ansible-community-package-and-collection-removal-roadmap/46563/20 "2026-10-31T15:44:20Z")
One thing to note is that Python allows you to create namespace packages, so you can install several collections packages under the expected community namespace. [PEP 420 – Implicit Namespace Packages | peps.python.org](https://peps.python.org/pep-0420/) Another thing I’ve been proposing for a long time is a ‘boostraping’ play that can be run on collection install, that would take care of non ansible dependencies, but this can get complicated and has to tackle many things, I have not gone to detail somewhere I can find right now and don’t really mean to hijack this thread, but here is a short version of what could lay the ground work to make community collection packages simpler to manage: - First, it must be optional: it cannot run by default as this would create a very easy to exploit method of running things on a user’s system. My plan, having this as a named playbook in the collection named ‘bootstrap’ or ‘install’. - All actions logged, easy to do via a callback. Where/how to store this log, that is something I thought should go along with the current manifest. - It has handle both controller and target dependencies, most plugins execute on the controller, modules (and module\_utils included in them) can execute on targets, most networking and cloud modules are normally executed on the controller also. The solution I proposed was a convention ‘controller’ and ‘targets’ for the bootstrap play could take care of that with the user having to assign those depending on their local inventories. - Multiple OS support, this is a lot harder, while package names have been normalizing across platforms, they are still distinct, `package` and `service` actions can help up to a point, but things like venvs can make things ‘fun’ and complicated. Here I had no real good solutions, but betting that collection authors would end up creating conventions and patterns that would end up as ‘good practices’. Execution Environments (via `ansible-builder`) are a good solution, but that normally requires a more ‘enterprise’ context, mostly designed around RHEL and not something all users will feel comfortable with. - cleanup, is something we don’t even do in `ansible-galaxy`, there is no uninstall. While it easy to remove the collection directory, it is not that easy to reverse uninstalling dependencies or any other actions taken, specially when it is not really recorded anywhere, why in bootstrapping above I wanted logging. This can get really complicated when several collections overlap in dependencies and can be installed from different controllers. This got a bit longer than expected, sorry for the wall of text. --- _[View the full topic](https://forum.ansible.com/t/proposal-trimming-down-the-ansible-community-package-and-collection-removal-roadmap/46563)._