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

181–190 of 214 posts

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

#181

Post by pas »

dragonwriter wrote: post #66
1f60c wrote: post #53

Earlier quoted context omitted.

As far as I know, Pip doesn't have the notion of dev dependencies, so you need at least two requirements[.dev].txt files.

> As far as I know, Python doesn't have the notion of dev dependencies Python doesn't have the notion of dependencies. Pip doesn't have dev dependencies, poetry does.

That's (the deps, not the dev deps) likely to change with pip 20.3! All hail the dependency resolver.

It's already available behind a feature flag.

https://pythoninsider.blogspot.com/2020/07/upgrade-pip-20-2-...

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

#182

Post by dijit »

pas wrote: post #180
pm215 wrote: post #163

Earlier quoted context omitted.

I think there are similarities -- the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?

Where should it go? Just like the gitlab-ci.yml, it handles things related to the whole repo, it basically runs a script in the root of the repo anyway. Sure, supporting other paths is useful (eg. in case of a monorepo), but this default seems sane. Though I'm interested in where others move it, and why.

it's pretty common to have a .ci folder for your build scripts.

But nothing is fundamentally wrong either with XDG-esque directory structures.

.config/travis/

.ci/travis/

all the same to me, as long as it's consistent.

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

#183

Post by bmn__ »

hedora wrote: post #141
tomc1985 wrote: post #114

Earlier quoted context omitted.

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

Now, half of them are in ~/.config This is better because it means you have to look in more places. Similarly, things also like to hide state in ~/.cache If they didn’t then rm -rf .appname would restore it to default settings, and we can’t have that.

I notice you chose to exclusively point out the negative aspects.

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

#184

Post by bryanrasmussen »

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…

I totally agree with this except - just when I was done with reading this thread I went back to the project I was on and I noticed there was some file in the root of the project red in VSCode so I go look at it, it's a JSConfig.json wtf is that I don't remember that config.

It says

{ "compilerOptions": { "baseUrl": "./" }, "exclude": [ "node_modules" ] }

I go google what it is, seems to be some VSCode thing added automatically maybe? https://code.visualstudio.com/docs/languages/jsconfig

but VSCode thinks it should be marked red, something is wrong with this config file I have no familiarity with. grrr.

anyway - I think at some point, especially on projects with lots of devs and lots of tooling, you look at the root and like art you know what you like or don't like and sometimes there will be a feeling that there are just too many files here for configuring stuff! But probably that indicates some other underlying problem, not a problem with having config files in itself.

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

#185

Post by layoutIfNeeded »

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.

Linearly? I’d say quadratically.

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

#186

Post by dkdk8283 »

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

I’ve never had a problem using find and grep -R

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

#187

Post by thiht »

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.

That's short-sighted. What about repos containing eg. a frontend and a backend? I did that with a Go/React project and I naturally ended up with: eslint conf, prettier conf, tsconfig, package.json, yarn.lock, editorconfig, Makefile, jest config, go.mod/go.sum, golangcilint.yml, Docker file/.dockerignore and travis.yml. Tell me, what should I discard?

And no, splitting the Go part and the React part is not an option as it makes releasing ten times harder.

Telling people to "just use fewer tools" might make you feel clever, but it's just snarky, really.

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

#188

Post by hakre »

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…

Good point, never had a problem to place the configuration files where they belong to, be it in the project root or not, until I figured it out. That's what software configuration management is for, and SCM is obviously in place (given this is a reported issue on Github).

And if you allow me to build on the "Finally" note in your comment with a personal note:

Some _human readable_ content belongs into the root as well, e.g. a read-me, information under which conditions the code can be used (copying info) and similar, the important stuff. Otherwise it would mean it only needs to be machine read-able (which can be fine, too, especially for pure configuration management, still though a repository will most likely checked out by a human from time to time).

Uncle Bob raises this question from time to time: When you checkout a repository and look into the tree, what do you see?

The root is always an opportunity to show the projects' birds-view.

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

#189

Post by ralphstodomingo »

bryanrasmussen wrote: post #184
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…

I totally agree with this except - just when I was done with reading this thread I went back to the project I was on and I noticed there was some file in the root of the project red in VSCode so I go look at it, it's a JSConfig.json wtf is that I don't remember that config. It says { "compilerOptions": { "baseUrl": "./" }, "exclude": [ "node_modules" ] } I go google what it is, seems to be some VSCode thing added aut…

Yeah - I think that's a cue pointing to you that your understanding of the project at hand may be lacking in some regard. I usually listen to that signal and learn the heck out of the current tooling whose config I see on the root before proceeding with the subdirectories.

That feeling of mild anxiety in not knowing why these files are there can be useful, is all I'm saying.

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

#190

Post by LoSboccacc »

what's the difference between /tool.cfg and /tool/tool.cfg?

if your project is a hodgepodge of tooling the problem is the hodgepodge of tooling in your project, maybe you need to nest modules or to split libraries, instead of changing everyone else sane defaults because modern hip toolchains can't handle dependents and nested subprojects without stepping on each other toes or requiring the full lib in a single place

Post reply on HN