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

81–90 of 214 posts

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

#81

Post by jolux »

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.

I tend to see a glut of tooling as a sign that a language has serious design flaws, as most important things should be done by the compiler, but I’d rather have JavaScript with proper tooling and types than nothing at all.

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

#83

Post by [deleted] »

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…

[deleted]

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

#84

Post by kardos »

dahfizz wrote: post #71
_8j50 wrote: post #43

How come /usr/etc/ didn't become popular?

What's the advantage over plain old /etc ? I am always annoyed by /bin, /usr/bin, /usr/share/bin, and others. Why can't we consolidate?

We did?

https://fedoraproject.org/wiki/Features/UsrMove

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

#85

Post by LukeShu »

marcosdumay wrote: post #49
benrbray wrote: post #32

Earlier quoted context omitted.

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?

Nope, he means the "new" LSB preferred directory for user-level configurations. "New" being quoted here because it's around a decade old already.

Nit: ~/.config is specified by XDG, not by LSB.

But yeah, the most recent revision of the XDG basedir spec is dated November 2010; we've had it for a decade.

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

#86

Post by johnwalkr »

Fully agreed but if everything is in one folder out of the it doesn’t need to be hidden anymore, it could be “config” instead of “.config”. Maybe even “config” (project config inside version control) and “.user-config” (project config by developer not inside version control). The issue hints at this but deliberately descopes user configs. Files inside the folders could have a dot depending on if they are normally edited throughout development or normally left alone.

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

#87

Post by jonoc »

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.

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

#88

Post by jjoonathan »

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.

But there are usually several versions of python with several pips, possibly in combination with anaconda with multiple environments, a combination of named and rolling releases, and a SAT solver that's always slow but occasionally spontaneously decides to become extra slow and extend your build time by hours.

Oh and I forgot about setup.py. That too.

Post reply on HN