Hi all,
We're happy to announce that the Ansible 5.3.0 package has been released !
Ansible 5.3.0 includes the newly released ansible-core 2.12.2 as well as
a curated set of Ansible collections to provide a vast number of
modules and plugins.
This is a major version update from Ansible 4.x which included
ansible-core 2.11 and there may be backwards incompatibilities in the
core playbook language.
Please see the porting guide (linked at the bottom) for details.
How to get it
I hate to sound like a broken record here, but could we please stop
claiming that ansible-core is included in ansible? It is a listed
requirement in the requirements.txt of the ansible package, but that
is really not the same thing as actually including any of the same
code or built in same compilation step. ansible-core can be installed
quite distinctly, for example by people who want to work around the
python 3.8 requirement for a RHEL 7 or RHEL 8 system and do this:
pip3 install --user ansible-core
# Installs ansible-core 2.11.8, for which EPEL has not
published an RPM yet, despite my publishing .spec files for it.
pip3 install --user ansible --nodeps
# Installs latest ansible, which works well with ansible-core
2.11 in smoke testing
I've updated my spec files for this for RHEL users, over at"
https://github.com/nkadel/ansiblerepo/
It has some other tweaks, such as gracefully handling the hundreds of
license and README files, and forcing "#!/usr/bin/python3" instead of
"#!/usr/bin/python" for consistency and successful RPM compilation.
Nico Kadel-Garcia <nkadel@gmail.com>
Nico Kadel-Garcia
Hi Nico,
> Ansible 5.3.0 includes the newly released ansible-core 2.12.2 as
> well as a curated set of Ansible collections to provide a vast
> number of modules and plugins.I hate to sound like a broken record here, but could we please stop
claiming that ansible-core is included in ansible?
no, because that is how we see the Ansible (PyPi) package. Ansible is
the "batteries included" package containing (!) both ansible-core and a
set of community collections. And it is what the docsite
(https://docs.ansible.com/ansible/5/) is describing: it describes both
ansible-core 2.12, the builtin collection of this version ansible-core
(see ansible.builtin in
https://docs.ansible.com/ansible/5/collections/), and a set of
collections included (see the other collections in
https://docs.ansible.com/ansible/5/collections/).
While technically you are right, the contents of the Ansible PyPi
package are a Python module that depends on the ansible-core Python
module, this is not what users expect if they install it, and not what
we document on our docsite. It is - from our point of view - merely an
implementation detail of how we realize what we are documenting and
want to deliver to our users.
It is a listed requirement in the requirements.txt of the ansible
package,
(Technical fine print: it is not. There is no requirements.txt file.
The dependencies are specified in setup.py. The might move to setup.cfg
in the future.)
but that is really not the same thing as actually including
any of the same code or built in same compilation step. ansible-core
can be installed quite distinctly, for example by people who want to
work around the python 3.8 requirement for a RHEL 7 or RHEL 8 system
and do this:pip3 install --user ansible-core
# Installs ansible-core 2.11.8, for which EPEL has not
published an RPM yet, despite my publishing .spec files for it.
pip3 install --user ansible --nodeps
# Installs latest ansible, which works well with ansible-core
2.11 in smoke testing
While you can install the Python module ansible-core 2.11.x with the
Python module ansible 5.x.y, the result will **not** be Ansible 5 (as
documented on https://docs.ansible.com/ansible/5/ or currently also
https://docs.ansible.com/ansible/latest/).
Cheers,
Felix
While technically you are right, the contents of the Ansible PyPi
package are a Python module that depends on the ansible-core Python
module, this is not what users expect if they install it, and not what
we document on our docsite. It is - from our point of view - merely an
implementation detail of how we realize what we are documenting and
want to deliver to our users.
If it's merely an implementation detail, why insist on stating it
incorrectly? Why not be more technically correct and use the verb
"requires" rather than "includes"?
Using "requires" would help reduce the likelihood of people installing
the quite bulky "ansible" package when all they really need is
"ansible-core" and perhaps a few "ansible galaxy" statements. That
would reduce burdens on pypi.org, and shrink deployed OS image sizes
by roughly 500 MByte, a bit of deployment economy that would be aided
by more clear language in the documentation.
Right now, I'm hoping to clarify some release language. Documentation
language could be next, but if it can be clarified in both, *great*.
It is a listed requirement in the requirements.txt of the ansible
package,
(Technical fine print: it is not. There is no requirements.txt file.
The dependencies are specified in setup.py. They might move to setup.cfg
in the future.)
Good point, thank you for the correction.
I've other thoughts about the way that tarball is assembled, which is
a very separate line of discussion.
While you can install the Python module ansible-core 2.11.x with the
Python module ansible 5.x.y, the result will **not** be Ansible 5 (as
documented on https://docs.ansible.com/ansible/5/ or currently also
https://docs.ansible.com/ansible/latest/).
This documentation... well, it has other issues. For example, it
mentions that to install "ansible" on RHEL based operating systems,
you should use EPEL to get current releases. That doesn't work, the
EPEL release is ansible-2.9.27 right now, and that release lacks the
"ansible" and "ansible-core" split architecture.