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?
The creeping scourge of tooling config files in project root directories
71–80 of 214 posts
Re: The creeping scourge of tooling config files in project root directories
#72Earlier 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.
D’oh! Thanks. :)
Re: The creeping scourge of tooling config files in project root directories
#73On 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.
[deleted]
Re: The creeping scourge of tooling config files in project root directories
#74The root is the right place for project-wide settings.
GitHub and other tools should do what ls does and hide dotfiles by default. That’s why they are dotfiles.
Other project-unrelated config/metadata should follow the .git example and use dotfile config files, preferably yaml or something similar (not json, as it does not support comments).
Re: The creeping scourge of tooling config files in project root directories
#75The 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.
Systemd pokes its head around the corner. Build tools? Its stomach rumbles. The beast hungers.
Re: The creeping scourge of tooling config files in project root directories
#76This is a problem I've encountered on my projects. I just want to nestle them all in a `config/` folder. Alas, lots of the tools really dislike if you would like a configuration in a spot other than the root directory. Suddenly you get to enjoy debugging all the times some functionality wants to be relative to the config directory instead.
I love the idea of a standard config file, but... Cross-project standardization in the JS ecosystem? Unlikely.
Re: The creeping scourge of tooling config files in project root directories
#77On 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.
Thankfully more and more projects are moving to respecting XDG_CONFIG_DIR:
The holdouts fall into the following categories:
1. Projects where the author doesn't care but would take a PR.
2. "My tool is super simple and I don't want to complicate it to read env vars or have platform specific config"
3. Projects which value cross platform consistency over consistency with the platform (tmux, though the next version does budge a little)
4. Projects which consider XDG as just "some desktop Linux thing" and don't consider themselves as caring about desktop that much or just that they predate XDG (SSH)
5. Projects who mix runtime and config and cached data in a single directory and don't want to split them out for proper XDG support.
The ArchWiki probably has the best centralised tracking of attempts to get XDG support implemented: https://wiki.archlinux.org/index.php/XDG_Base_Directory
Re: The creeping scourge of tooling config files in project root directories
#78Earlier 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…
When I first set up my requirements.txt's, I usually set up a venv, install the things that I need and then run "pip freeze" to get a list of all deps including transitive deps, and put them all in the requirements.txts.
I do sometimes feel that people are making rube goldberg machines out of their package management in an attempt to avoid just writing down all their deps.
Re: The creeping scourge of tooling config files in project root directories
#79I 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 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 makes sense for configs that could ostensibly do this, but that's only a fraction of them. Regardless of what we do about those (if anything), the other ones at least shouldn't be laid out like this.
Re: The creeping scourge of tooling config files in project root directories
#80Earlier 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…
>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
Isn't that what pip freeze is for?