[brunooliv]

I think while the basic idea of advocating for stack consistency between the main project and any support scripts is very nice, I always find it not worthy to pursue in practice for several reasons: a lot of the “environment” around the main codebase will be a weird mix of YAML, bash and a scripting language like Python or Ruby for things like gitlab, airflow, GitHub actions, etc. Given this heterogeneity of the project environment and additional complexity of “forcing” something to use a language it might not be very well suited for, makes this really a no brainer for me: use the most convenient tool for the job. Plus as a JVM bound developer I love me my occasional Python

[treyd]

I agree with this sentiment. At work our main codebase is in Rust and early on we wrote some CI tooling using the cargo xtask workflow and it adds a lot to compile times when we need to rebuild it (which is often since it depends on several of our main codebase's crates). It really kills iteration times.

This is a mess and added a lot of extra complexity to the build pipeline since now we had to manage an additional xtask container. Python is very well suited for CI scripting, xtask should only be used for things directly run by the developer, and even then Python may be a better choice for most things.