The creeping scourge of tooling config files in project root directories
11–20 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#12Also, please don't use dotfiles. There is no reason to hide such important files.
Re: The creeping scourge of tooling config files in project root directories
#13I know some tools allow you to specify the location of your config files, and it would be nice if all tools started to do that.
Re: The creeping scourge of tooling config files in project root directories
#14Also, please don't use dotfiles. There is no reason to hide such important files.
Re: The creeping scourge of tooling config files in project root directories
#15I 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 f…
Re: The creeping scourge of tooling config files in project root directories
#16Put everything in a folder, and use a namespace, e.g.:
org.organization-name.project.jsonRe: The creeping scourge of tooling config files in project root directories
#17Also, please don't use dotfiles. There is no reason to hide such important files.
Re: The creeping scourge of tooling config files in project root directories
#18It'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.
Edit to add— someone suggests this on the linked issue, and it is mentioned as a concern that auto-hiding the files could lead to them being used to conceal malicious code. Not sure how significant of a concern that really is, but it's an interesting angle, anyway.
Re: The creeping scourge of tooling config files in project root directories
#19Re: The creeping scourge of tooling config files in project root directories
#20How 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.…