TOML configuration file naming

Project Discussions
1

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. 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?

1 Like
2

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, 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…

1 Like
3

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.

1 Like
4

@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:

[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.