I feel like this must have been discussed a hundred times before but, since this is about the ACP, wouldn’t it be more consistent, if nothing else, to be referring to it as such?
I mean, not only here in the vote, but throughout the actual roadmap.
I usually try to say Ansible Community Package or ACP. Although I have to admit that I often say just plain Ansible. After all, that’s the package name and less typing than “Ansible Community Package” and somehow smoother(?) than ACP.
When it comes to the roadmap, I don’t want to change the PR now that the vote is already active. I’m fine replacing Ansible with Ansible Community Package / ACP there in a second step, though. If nobody objects, that is.
edit: @russoz Pretty OT, but I’ve changed Ansible to ACP here and here.
I don’t think we have an official name yet, other than “Ansible” (which has too many overloads). While Ansible Community Package (ACP) is quite common, we never decided on it as the “official” name of the package. Maybe we should have a vote on that topic 
1 Like
I’ve always used ‘ansible community distribution’ (ACD), but has never caught on.
OT, but:
I don’t remember seeing Ansible Community Distribution / ACD anywhere. But I think it makes as much sense as Ansible Community Package. Maybe distribution is even better than package.
Before we vote, I think we should discuss this. I’m pretty sure I’ve seen a discussion about this: How to name things in Ansible-land? Ansible Core, AAP, the Ansible Community Package and the rest of the ecosystem. I’m not 100% sure if this is the one I’ve had in mind, but it would fit.
Maybe we could move the discussion about Ansible / ACP / ACD / whatever to there. Or create a new thread mentioning this one.
1 Like
This is something I wrote a while back when starting conversations with new people … mostly because it was exhausting correcting assumptions 2h into a conversation of people talking about different things with same name:
The ONE true ansible
TLDR, confusingly ‘ansible’ can refer to the installer package (pypi, ppa), the repo (github.com/ansible/ansible), the RH product (AAP) or the CLI tools ( bin/ansible*) and sometimes the core/base/engine … depending on context. To avoid confusion always try to use alternate terms or add specificity (the ansible package, the ansible repo, etc).
The following is the full list and explanation of what many people can mean by ‘ansible’.
ansible(automation platform): Also known as AAP, the suite of tools (28 on my last check) centered around Controller (formerly Tower, formerly awx, formerly Commander). The tools all have upstream projects, many times multiple per tool/sub product.
ansible(community distribution): ACD for short, this term was the original name of the ansible packaging project for versions >= 2.10, but was publicly dropped in favor of ‘ansible’. The community team stresses that we should never publicly use this term. Some still use it internally to make the distinction as the generic ‘ansible’ is too confusing.
ansible(package): since 2.10, for our ppa and pypi this currently contains the community team’s ansible distribution, mostly the selection of collections they curate and it depends on the ansible-base/core package (which contains the ansible CLI tools). https://github.com/ansible-community/ansible-build-data. For versions <= 2.9 it contains the ‘old kitchen sync’ ansible, from the ansible(repo) in the older stable branches.
ansible(repo): basically https://github.com/ansible/ansbile which had the full (ignoring modules’ short hiatus) ansible package up to 2.9 and only base/core >=2.10.
ansible(CLI): Command Line Interface, basically the executables ansible, ansible-playbook, ansible-inventory, etc. Note: --version is always corresponding to the ansible(repo), even if installed as a dependency of ACD.
ansible-base(package): this is the ‘minimal ansible’ after the collection split hosted in the ansible/ansible github repo. This has the core code of ansible, the CLI and a minimal set of plugins. ONLY version 2.10.
ansible-core(package, project): same as ansible-base but for versions >=2.11 as the name ‘ansible-base’ was found to not be as marketable. We also use ‘core’ as a short disambiguation.
ansible-engine(rpm, product): this is the discontinued (after 2.9) ‘supported’ downstream version of ansible CLI. There are no longer any official rpms for RHEL. Sometimes people refer to ansible-core/base as ‘the engine’ but this is just confusing.
Unrelated to RHEL installs of ansible-core as part of RHEL system roles.
2 Likes
We could consider changing the name of ansible on PyPI to ansible-community, but I’m not sure if that is worth the trouble or would result in a net decrease in confusion. The ansible package currently provides an ansible-community CLI entrypoint that prints the current version, so there is some precedent for this name.
Generally, I try to refer to it as “the ansible community package” in cases where it might be ambiguous. When I’m talking about ansible and ansible-core together, I might use those names in monospace, to refer to the package names, or use “Ansible” and “Core” (capitalized). But yes, it’s all a bit confusing/ambiguous.
To clarify, i’m not advocating for package renaming, the ACD reference is something I use to disambiguate the projects when talking about them.
The text i posted above was written after the 100th time a random pearson(s) asked me an ambiguous question about ‘ansible’ w/o any context and we all lost time down answers that applied to the ‘wrong’ ansible. It has helped decrease my frustration levels, I only offered it in case it could do the same for others.
Between collections, this forum, matrix, etc., “community” has become almost as useless as “ansible”. Though well-intended, I don’t believe this discussion is solving the problem; it’s just stirring the (alphabet) soup.
@utoddl I also have to define the scope of ‘community’ every time it comes up in a conversation, as many people also assign very different meanings to the term.