unit 1 · Orientation
ansible-core vs the community package
Two packages, one engine — and two version numbers
tl;dr
- ansible-core = the engine plus the ansible.builtin collection only. Minimal by design.
- The ansible community package = core plus a big curated bundle of collections — batteries included.
- Two version tracks: each community major pins one core series, and only the latest major is maintained.
why it matters Install the wrong package and half the modules in your team’s playbooks don’t exist; misread the two version tracks and you’ll debug against docs for a release you aren’t running.
Type pip install ansible and you get one thing. Type
pip install ansible-core and you get something much smaller. Same engine,
same commands — the difference is what ships alongside it.
ansible-core is the engine: the ansible and ansible-playbook
commands, the plugin machinery, and exactly one collection of modules —
ansible.builtin. It’s deliberately minimal: you install only the
collections you actually need.
ansible — the community package — is ansible-core plus a large curated bundle: more than 85+ collections containing thousands of modules and plugins. It restores the batteries-included experience from before the collections split, when everything shipped as one monolith.
What it means day to day
# Batteries included: engine + the curated bundle, pre-installed
pip install ansible
# Just the engine + ansible.builtin — you add collections yourself
pip install ansible-core
ansible-galaxy collection install community.general # pinning: lesson 26
ansible --version # verify either installThe bundle makes things work out of the box; bare core trades that for a footprint you control. One wrinkle for later: in AWX and Ansible Automation Platform neither model applies: collections are baked into an execution-environment container image instead — lesson 40 covers that.
Two packages means two version numbers
Each package has its own version track — this is where colleagues, docs and error messages will confuse you. Today the community package sits at major 14 , riding on ansible-core 2.21 . That pairing is the rule: each community major pins exactly one core series, published in the official release announcements.
The cadence is quick. The community package cuts roughly two majors a year with a new minor every four weeks, and only the latest major is maintained — no long-term-support branch to hide on. ansible-core moves slower and maintains three majors at a time under graduated support windows, so every release you run has a published end-of-life date. Check those dates on endoflife.date before an upgrade conversation, as you would an Azure API retirement date. Each core series also sets a floor for the control node’s Python: core 2.21 tracks Python 3.12–3.14 .
One engine, two packages, two version tracks, short support windows. What’s left is what’s inside that bundle — collections, each with a namespace that changes how every module name is written. That’s the next lesson, and why most old tutorials will lie to you.
at work, this sounds like
- “Are we on bare core or the full package?”
- Which pip package the control node has — ansible-core (install collections yourself) or ansible (bundle pre-installed).
- “The EE already has that collection baked in.”
- In AWX/AAP, collections ship inside an execution-environment container image, not on the control node.
self-check — recall, not a test
1 Same engine either way — so what does pip install ansible give you that pip install ansible-core doesn’t?
2 A colleague quotes one version number, the docs quote a completely different one. Contradiction?
3 How often does the community package move, and how many of its majors stay maintained?