# TOML configuration file naming

**URL:** <https://forum.ansible.com/t/toml-configuration-file-naming/43867>\
**Category:** Project Discussions\
**Tags:** antsibull-nox\
**Created:** [July 14, 2025, 11:34am UTC](https://forum.ansible.com/t/toml-configuration-file-naming/43867 "2025-07-14T11:34:42Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![oranod](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/oranod/32/1434_2.png) [@oranod](https://forum.ansible.com/u/oranod)\
**Post date:** [July 14, 2025, 11:34am UTC](https://forum.ansible.com/t/toml-configuration-file-naming/43867/1 "2025-07-14T11:34:42Z")

</div>

Had a thought after some experimentation…

Yes, the name of the file (`antsibull-nox.toml`) is descriptive because it holds configuration for a specific tool.

But is that name as meaningful when we take the view of the collection developer? In that case, would something like `ansible-collection-checks.toml` be more fitting?

After all [TOML prioritizes humans](https://toml.io/en/). Humans use tools to achieve a goal. So putting the focus on that motivation in config file naming doesn’t seem too wild of an idea.

Within the project, you can almost immediately derive the meaning of a file named `ansible-collection-checks.toml`. This seems to be in keeping with TOML’s philosophy of obvious semantics. It would likely benefit new contributors and maintainers to collections.

I also wonder if `ansible-collection-checks.toml` could hold configuration for other tooling and reduce file clutter in the project root.

What do others think?

---

<div class="post-metadata">

**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\
**Post date:** [July 14, 2025, 1:10pm UTC](https://forum.ansible.com/t/toml-configuration-file-naming/43867/2 "2025-07-14T13:10:16Z")

</div>

One problem I see with `ansible-collection-checks.toml` I see is that it is a very official name: I would expect the file contents to be documented in [Ansible Documentation — Ansible Community Documentation](http://docs.ansible.com/ansible/devel/), and supported by tools like ansible-test and ansible-lint (and not just antsibull-nox, which doesn’t even have ‘ansible’ in its name). Not sure whether it’s just me or whether other would also interpret that filename this way though…

---

<div class="post-metadata">

**Author:** ![Lyle\_McKarns](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/lyle_mckarns/32/8142_2.png) [@Lyle\_McKarns](https://forum.ansible.com/u/Lyle_McKarns)\
**Post date:** [July 14, 2025, 2:05pm UTC](https://forum.ansible.com/t/toml-configuration-file-naming/43867/3 "2025-07-14T14:05:18Z")

</div>

I think you’re both correct here. I like the idea of consolidating configuration into a single file with sections. But that feels like a top-down change, not a bottom up change.

---

<div class="post-metadata">

**Author:** ![oranod](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/oranod/32/1434_2.png) [@oranod](https://forum.ansible.com/u/oranod)\
**Post date:** [July 14, 2025, 3:26pm UTC](https://forum.ansible.com/t/toml-configuration-file-naming/43867/4 "2025-07-14T15:26:25Z")

</div>

@cidrblock I’d be curious about your take on all this.

I’m going to answer my own question about having a file that could hold configuration for tools other than `antsibull-nox`. @felixfontein mentioned the need for such a file to be supported by the likes of ansible-test and ansible-lint.

But I think an even better candidate is tox-ansible. I’ve been looking at `tox-ansible.ini` lately. When starting out, it is super confusing to know which tools to use, when to use them, and where they overlap. Maybe `antsibull-nox` and `tox-ansible` are not really compatible for some reason that I’m not aware of. However it seems to me that the `tox-ansible` approach is more for covering many environments and breadth of coverage while `antsibull-nox` is more for depth of coverage. So they seem quite complementary in that way.

Having a single TOML config file could help clarify things like that from the user perspective. Consider something like this:

```auto
[testing.matrix]
python_versions = ["3.11", "3.12", "3.13"]
ansible_versions = ["2.18", "2.19", "devel"]
runner = "tox-ansible"

[testing.development]
lint = true
format = true
docs_check = true
runner = "antsibull-nox"

```

This would make the capabilities of each tool more explicit from my view.