The creeping scourge of tooling config files in project root directories
1–10 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#2I 100% agree on this. But it's been pretty hilarious on how obstinate tool makers are about changing to Python's new pyproject.toml [1]
Python packaging is a bit of a mess already, so when I recently started a new small package I wanted to choose tooling that would not clutter, but a fair amount of tool makers were reluctant to allow code into their repo that would use the unified toml rather than a ton of separate file.
.config is probably a better solution than a single top level toml, IMHO, but far more important is doing something unified rather than continuing the pollution of the top-level namespace, which merely obscures the project structure.
Re: The creeping scourge of tooling config files in project root directories
#3How conscientious.
And yup, conventions like this work well Linux and BSD's. To note ~/.config for many configs
These days you see this happening inside of .github/, where configs related to gh repos and actions go.
If tooling authors started universally recognizing .config/ as a directory where we could keep stuff, the root could be super clean.
How about just one file, across languages / CI tools / etc? a "project.toml" or "project.yaml" or "project.json"?
[tool.npm]
name = "frontend"
version = "1.0.2"
[tool.npm.dependencies]
react = "^16.3.1"
[tool.travis-ci]
# ...
[tool.eslint]
# ...
[tool.poetry]
name = "backend"
[tool.poetry.dependencies]
django = "~3.1.0"
Legacy configs could be ported via YAML / JSON straight into the TOML sections. It'd work for package.json or tslint.json, but not stuff involving runtime, e.g. .eslintrc.js
Re: The creeping scourge of tooling config files in project root directories
#4I mean, for most tools it would be pretty easy to look at .config/ first and then at the project root - and print something about the new best practice.
The whole thing is a little uncomfortable though. There is a clear isomorphism between the contents of the structure of, say, a JSON file, and the contents of a directory of structured text files (and other directories). Heck, you could build a little tool with a slider that moves all the data between a single file, and a deep directory hierarchy with lots of tiny text files as the leaves.
Personally I feel like the best solution is to somehow "indelibly" combine the tool with its config within a project, de facto removing all config options from the developer. In the worst case, it could be something as silly as a wrapper script with config embedded in there. Of course this is a kind of fiction, but a useful one. It feels nice to get to a point where you don't have to think about tooling. (The last time for me was like 2000).
Re: The creeping scourge of tooling config files in project root directories
#5It's probably too late to change every tool.
If the main problem is that, when you go look at a project on github or gitlab, you see a long list of config files rather than the code you're looking for, a cleaner solution is for the git sites to show the listing for a /src directory instead of / on the project page.
Re: The creeping scourge of tooling config files in project root directories
#6It's probably too late to change every tool. If the main problem is that, when you go look at a project on github or gitlab, you see a long list of config files rather than the code you're looking for, a cleaner solution is for the git sites to show the listing for a /src directory instead of / on the project page.
[deleted]
Re: The creeping scourge of tooling config files in project root directories
#7[deleted]
Re: The creeping scourge of tooling config files in project root directories
#8I mean, for most tools it would be pretty easy to look at .config/ first and then at the project root - and print something about the new best practice. The whole thing is a little uncomfortable though. There is a clear isomorphism between the contents of the structure of, say, a JSON file, and the contents of a directory of structured text files (and other directories). Heck, you could build a little tool with a sli…
> In the worst case, it could be something as silly as a wrapper script with config embedded in there.
That's not a terrible idea. For me, I really like tools such as 'nft' that take advantage of the shebang line to solve more or less this exact problem.
Re: The creeping scourge of tooling config files in project root directories
#9It's probably too late to change every tool. If the main problem is that, when you go look at a project on github or gitlab, you see a long list of config files rather than the code you're looking for, a cleaner solution is for the git sites to show the listing for a /src directory instead of / on the project page.
Or hide/collapse dotfiles like the ls command does.
Re: The creeping scourge of tooling config files in project root directories
#10How conscientious. And yup, conventions like this work well Linux and BSD's. To note ~/.config for many configs These days you see this happening inside of .github/, where configs related to gh repos and actions go. If tooling authors started universally recognizing .config/ as a directory where we could keep stuff, the root could be super clean. How about just one file, across languages / CI tools / etc? a "project.…
I like the idea of a single consolidated config file as long as:
1. It supports real comments (so not json) 2. It supports imports/includes so if it gets unwieldy it can be split up.