Live data from Hacker News

The creeping scourge of tooling config files in project root directories

github.com

21–30 of 214 posts

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

#21

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 don’t think this is true. I’ve personally seen the following (and I’m positive there are others):

1. setup.py with self contained dependencies (this is my general preference)

2. setup.py loading from requirements.txt

3. Standalone requirements.txt

4. requirements.txt generated from requirements.in (or similar)

5. pyproject.toml + Poetry with a dependencies section

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

#22

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.

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 (other tools use a content checksum). This can cause a long tail of reproducibility and maintenance issues.

It’s also a tiny subset of what the parent describes.

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

#23
post #12

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

`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.

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

#24
post #12

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

I think you have to configure osx finder to not hide them. Android seems to use the . prefix to hide images in the image gallery.

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

#25

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.

This is a big oversimplification. There are often multiple setup.txt files for different environments, virtualenv setup scripts, tox files, several different build config files, manifest files, and so on. Python probably has more magic config files than C#, which is quite an accomplishment.

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

#29
post #12

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

*nix systems hide dotfiles by default. Some file browsers may show them. It's been a while since Linux was a daily driver for me, but it would surprise me if any of the standard/common ones showed dotfiles by default. On macOS they're hidden in Finder. I don't know about Windows, I think it shows them by default.

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

#30
post #13

In the screenshot in the article, 5 out of 8 are related to using JavaScript. Anecdotally, it does seem like more of a problem with Docker + JavaScript + Git in the same project. I 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.

It looks like the issue was opened against the tooling project of nodejs, so perhaps the author is trying to start with JavaScript. It is incredible how many of these files you get in a basic Node or React app however.
Post reply on HN