Who cares. Get over it.
If everybody had that attitude we'd still be hunting with sticks.
nonsense - files in the root of a directory does not stop progress. What an absurd analogy
The creeping scourge of tooling config files in project root directories
31–40 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#32On another note can we talk about the amount of projects that just dump their config/log files in the root directory as a 'hidden' file when you start them? Why? we have a .config for a reason.
Do you mean the system-level config folder? Won't that cause problems when A) you rename / move a folder or B) copy a folder to a different computer?
Re: The creeping scourge of tooling config files in project root directories
#33How 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.…
Windows goes a step further with AppData Local and Remote. Which is a good distinction for those of us who like to sync with roaming folder.
Sadly there's a confusing LocalLow and not all apps use AppData anyway. But it's something.
Re: The creeping scourge of tooling config files in project root directories
#34Also, please don't use dotfiles. There is no reason to hide such important files.
On which systems are they hidden? I hadn't even considered this issue because no file browser I've used in the last ~10 years has hidden dotfiles. Maybe Windows Explorer does, but that's a setting I typically change right away, so I don't even remember.
MacOS and many Linux distributions.
Re: The creeping scourge of tooling config files in project root directories
#35On another note can we talk about the amount of projects that just dump their config/log files in the root directory as a 'hidden' file when you start them? Why? we have a .config for a reason.
I think it’s so that all the configs float to the top and get out of the way. Agree that it’s annoying though.
Re: The creeping scourge of tooling config files in project root directories
#36How 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.…
Nah, it's far too common for tools to automatically update config files. A unified file would be asking for corruption, lost comments, trivial formatting and ordering changes, and more.
Re: The creeping scourge of tooling config files in project root directories
#37Earlier quoted context omitted.
On which systems are they hidden? I hadn't even considered this issue because no file browser I've used in the last ~10 years has hidden dotfiles. Maybe Windows Explorer does, but that's a setting I typically change right away, so I don't even remember.
`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.
i much prefer them to be hidden by default. i know they are there, but rarely do i need them. especially in something like `for i in $(ls -1)` type of commands. if i need them `alias 'lla = ls -la'`, 'alias 'la = ls -a'` are faves to now see what i'm looking for quickly
Re: The creeping scourge of tooling config files in project root directories
#38I'm using .config when I find it but for the last 15+ years on new projects, regardless of language I'd been making an `etc` directory and putting config in there.
Re: The creeping scourge of tooling config files in project root directories
#39Earlier quoted context omitted.
Python is unified on a requirements.txt file with pip, to manage dependencies.
requirements.txt has a lot of deficiencies for package management (compare to the various features Yarn or Cargo offer). The biggest weakness is transitive dependency locking: even if you specify the exact version of the dependencies you want, Pip can still resolve to a different version of their dependencies, and even then there’s no verification that the content matches what is expected beyond the version number (o…
It also can't separate dev vs test vs prod dependencies, for example. Maintaining separate files for those is not exactly a convenient solution
Re: The creeping scourge of tooling config files in project root directories
#40I 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…
Python is unified on a requirements.txt file with pip, to manage dependencies.
Not "a" requirements.txt file, sadly. I've seen packages with different requirements for building, installing, and testing. All with their own damned txt file. Oh! And don't forget the duplication in setup.py -- you'll want to put your requirements there, too.