Repository navigation
Rationalize ci/tools vs toolshed #3227
Description
In my mind, ci/tools should be a place for checks used in both CI and pre-commit, and toolshed used to automate development tasks. We currently have a blending / fuzzy line between these two concepts, and it might be worth rationalizing this.
Reacted by Ralf W. Grosse-Kunstleve and Leo Fang
Activity
leofang commentedon Oct 26, 2026
toolshedwas meant to be a dumpster of one-off scripts that are OK to delete and not used by any tests or CI pipelines. If a file is essential to any workflow, it needs to be moved out and placed in a new home.sylvesterkaczmarek commentedon Nov 6, 2026
I would like to take this on, following the distinction above. I propose moving checks required by CI or pre-commit from toolshed into ci/tools, updating workflow/hook/test references and relative paths, and leaving genuinely ad-hoc scripts in toolshed. I would preserve check behaviour and validate the affected scripts and hooks on Linux and Windows. Could a maintainer assign this issue to me or explicitly approve that scope before I start implementation? I have not started coding.
mdboom commentedon Nov 9, 2026
Thanks a lot for the offer, @sylvesterkaczmarek. This is very welcome, but I think we should hold off until after the whole #3322 (and the stack below it) is merged, because otherwise we are likely to have many merge conflicts. If you want to track #3322 and ping me again here when it is merged, I'd be happy to assign you then (I'll try to remember that myself).
sylvesterkaczmarek commentedon Nov 9, 2026
Thanks, @mdboom. That sequencing makes sense. I'll leave the tooling reorganisation alone while #3322 and the related stack are still in flight, so we avoid conflicting with those changes. Appreciate the guidance.