Creating reproducable environments
When running the ansible stuff localy i did create a new venv and installed a fresh ansible. The new version did throw some warnings but thats not what i want to get to just yet. Because this made me ask: How (if at all) do these repositories define their ansible and more general depency versions? There are not requirements.txt (not the same as requirements.yml, which is for ansible galaxy) so as far as i can tell there is nothing that does so. This will inevitably lead to ppeople running different ansible (and its dependencies) versions. For example the montioring role has a dependecy to the prometheus galaxy collection which does require the ansible core version to be <2.20. But if you install ansible today you will get ansible-core 2.20.2 because thats the current stable release: https://pypi.org/project/ansible-core/
A pyroject.toml to make PEP 518 ccompliant python projects
This would allow the repository to explicity define its required version dependecies. The pyproject.toml file is the gold standard in the python world to define a project. The python world has had its fair share of confusion over how to define a project (package) but after years of struggling the pyproject.toml is here to stay. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/
In a simple form one such file would look like this:
[project]
name = "bar-infra"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
requires-python = ">=3.13"
dependencies = [
"ansible<=13.0.0",
"ansible-core<=2.18.99"
]
A uv.lock to pin exact version dependencies. (Optional but highly recommended)
This works much like lock files in other build systems, where trees of exact versions of all dependencies are recorded. Similar to the pyproject.toml background (the python world having had a lot of troubles about what a package installable actually is), the uv tool written by Astral and release early 2024 has made significant impact in providing a simple developer experience to produce identical environments to run stuff from. https://docs.astral.sh/uv/
What would that mean for existing environments?
In short: Nothing! Both files are only relevant if you want to use them. If you already have set up a venv using python -m venv . you can absolutley still do so. However, if you would create a new environment, the pyproject.toml file would allow you to install that project into that environment using pip install . which would then install the defined ansible into that env as well. And if you would use uv, the uv.lock file would allow you to replicate exactly(!) the same environment as define (and commited to git) by that file. Which would leave to everybody running ansible in the exact same version dependecy tree. Besides this would allow to test different ansible version much easier, because ansible is not installed in the system, but the venv, and thus could easily be switched out (localy) and tested in different configurations.
Summarize
Two new files in all ansible-* playbook repositories, allowing us to provide an exact definition of the environment we expect ansible to be run from managed in git .
Creating reproducable environments
When running the ansible stuff localy i did create a new venv and installed a fresh ansible. The new version did throw some warnings but thats not what i want to get to just yet. Because this made me ask: How (if at all) do these repositories define their ansible and more general depency versions? There are not requirements.txt (not the same as requirements.yml, which is for ansible galaxy) so as far as i can tell there is nothing that does so. This will inevitably lead to ppeople running different ansible (and its dependencies) versions. For example the montioring role has a dependecy to the prometheus galaxy collection which does require the ansible core version to be <2.20. But if you install ansible today you will get ansible-core 2.20.2 because thats the current stable release: https://pypi.org/project/ansible-core/
A pyroject.toml to make PEP 518 ccompliant python projects
This would allow the repository to explicity define its required version dependecies. The pyproject.toml file is the gold standard in the python world to define a project. The python world has had its fair share of confusion over how to define a project (package) but after years of struggling the pyproject.toml is here to stay. https://packaging.python.org/en/latest/guides/writing-pyproject-toml/
In a simple form one such file would look like this:
A uv.lock to pin exact version dependencies. (Optional but highly recommended)
This works much like lock files in other build systems, where trees of exact versions of all dependencies are recorded. Similar to the pyproject.toml background (the python world having had a lot of troubles about what a package installable actually is), the
uvtool written by Astral and release early 2024 has made significant impact in providing a simple developer experience to produce identical environments to run stuff from. https://docs.astral.sh/uv/What would that mean for existing environments?
In short: Nothing! Both files are only relevant if you want to use them. If you already have set up a venv using
python -m venv .you can absolutley still do so. However, if you would create a new environment, the pyproject.toml file would allow you to install that project into that environment usingpip install .which would then install the defined ansible into that env as well. And if you would use uv, the uv.lock file would allow you to replicate exactly(!) the same environment as define (and commited to git) by that file. Which would leave to everybody running ansible in the exact same version dependecy tree. Besides this would allow to test different ansible version much easier, because ansible is not installed in the system, but the venv, and thus could easily be switched out (localy) and tested in different configurations.Summarize
Two new files in all ansible-* playbook repositories, allowing us to provide an exact definition of the environment we expect ansible to be run from managed in git .