Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The creeping scourge of tooling config files in project root directories

github.com

Post reply on HN
Print view View original

111–120 of 214 posts

Re: The creeping scourge of tooling config files in project root directories

#111

Post by tomc1985 »

Legogris wrote: post #95
ayroblu wrote: post #48

I don't get this, what's the problem here? Having config files in root means you know they can apply to all sub directories. This has nice properties like recursive behaviours (see .gitignore) If you want to put (most of) your config files in a .config folder, then most apps should support that If you want to view your config files in a different way, then actually you're trying to solve a different problem. Perhaps…

Yeah, I take a cluttered root dir over having to hunt down files I may not know exist in various places in order to fully understand a project I’m not the maintainer of. Gets me every time when a maintainer puts Dockerfile in some random subdirectory. If the root dir is full of dozens of files from all the tooling needed to build your software, maybe you have another problem than directory structure...

Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files

Re: The creeping scourge of tooling config files in project root directories

#113

Post by hnzix »

throw_m239339 wrote: post #112

The good old "conventions" vs "configuration" debate. Seems like Javascript looks more and more like Java with all these manifests. Though XML solved the issue of needing multiple config files long ago, with namespaces.

Now we just need to finish moving from REST to pseudo-RPC and we'll have come full circle back to the 90s. Does this mean I can put bevels on my UI buttons again?

Re: The creeping scourge of tooling config files in project root directories

#114

Post by tomc1985 »

mehrdadn wrote: post #104
themarkn wrote: post #102

Earlier quoted context omitted.

... “shouldn’t be laid out like this” doesn’t explain why it’s a _problem_ though. I’m curious about this as well. I think it’s fine as is.

Same reason why we have subdirectories in the first place and don't just shove everything into one directory. Same reason why you (hopefully) don't put everything on your desk and instead designate places for things, like in drawers. Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

> Same reason why we have a ~/.config folder now instead of just shoving everything into ~/ like we used to.

Who/what is the "we" here? Last I checked my homefolder was still chock full of dotfiles in-use.

Re: The creeping scourge of tooling config files in project root directories

#115

Post by taneq »

tengbretson wrote: post #56

The amount of pressure you feel telling you you are using too many tools should scale linearly with the number of tools you use. This discomfort you feel with seeing all of those config files is telling you something. Use fewer tools.

It's the same with libraries, IMO. Of course both tooling and libraries increase with the size of your project, but if either is disproportionately large compared with the size of the code involved, it's a bit smelly.

Re: The creeping scourge of tooling config files in project root directories

#116

Post by noskllzgap88 »

ayroblu wrote: post #48

I don't get this, what's the problem here? Having config files in root means you know they can apply to all sub directories. This has nice properties like recursive behaviours (see .gitignore) If you want to put (most of) your config files in a .config folder, then most apps should support that If you want to view your config files in a different way, then actually you're trying to solve a different problem. Perhaps…

The problem is someone anthropomorphized their code as “suffering” as justification to debate the color of the bike shed.

Re: The creeping scourge of tooling config files in project root directories

#117

Post by paulie_a »

user5994461 wrote: post #15
epistasis wrote: post #2

I 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.

I never have a unified requirements file.

Re: The creeping scourge of tooling config files in project root directories

#118

Post by tomc1985 »

jonoc wrote: post #87
tengbretson wrote: post #56

The amount of pressure you feel telling you you are using too many tools should scale linearly with the number of tools you use. This discomfort you feel with seeing all of those config files is telling you something. Use fewer tools.

Not sure I agree with this due to the fact that all projects are different and such their tooling requirements will be different. I don't think it's fair to just apply a blanket rule of 'use fewer tools' - this tends to end up with people writing their own implementation of existing tools which then turns in to tech debt so it's kind of a void argument.

I think this argument is more about utilizing minimalism in software design than always writing-it-yourself. IMHO many of us have seem to favor a form of feature maximalism, and perhaps we should be tempering our ambitions design-wise. Too much software has far too large a surface area.

Re: The creeping scourge of tooling config files in project root directories

#120

Post by smohare »

Legogris wrote: post #95
ayroblu wrote: post #48

I don't get this, what's the problem here? Having config files in root means you know they can apply to all sub directories. This has nice properties like recursive behaviours (see .gitignore) If you want to put (most of) your config files in a .config folder, then most apps should support that If you want to view your config files in a different way, then actually you're trying to solve a different problem. Perhaps…

Yeah, I take a cluttered root dir over having to hunt down files I may not know exist in various places in order to fully understand a project I’m not the maintainer of. Gets me every time when a maintainer puts Dockerfile in some random subdirectory. If the root dir is full of dozens of files from all the tooling needed to build your software, maybe you have another problem than directory structure...

The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess.

I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.

Post reply on HN