11 ms·
The creeping scourge of tooling config files in project root directories
- epistasis 6y agoI 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 file. .config is probably a better solution than a single top level toml, IMHO, but far more important is doing something unified rather than continuing the pollution of the top-level namespace, which merely obscures the project structure. [1] https://snarky.ca/what-the-heck-is-pyproject-toml/ https://snarky.ca/what-the-heck-is-pyproject-toml/
- user5994461 6y agoPython is unified on a requirements.txt file with pip, to manage dependencies.
- woodruffw 6y agoI 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
- wwright 6y agorequirements.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.
- bpicolo 6y agoIt also can't separate dev vs test vs prod dependencies, for example. Maintaining separate files for those is not exactly a convenient solution
- Sir_Substance 6y agoWhen 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.
- gruez 6y ago>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?
- lmm 6y agoThe trouble there is that if you freeze you can't unfreeze. A project needs the equivalent of both gemfile and gemfile.lock (unless you're using a system like maven that got things right the first time), but there's no standard way of having both of them in Python.
- HALtheWise 6y agoI strongly recommend https://github.com/jazzband/pip-tools https://github.com/jazzband/pip-tools to solve this. It provides a simple script to take a requirements file and "compile" a full specification of all transitive dependencies. You check both files into the repo, point pip at the generated file, and manually modify the other one. It means you often don't need to pin requirements manually at all, and the versions will be explicitly updated whenever you choose to recompile your requirements.
- jniedrauer 6y agoThis 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.
- klyrs 6y agoNot "a" requirements.txt file, sadly. I've seen packages with different requirements for building, installing, and testing. All with their own damned txt file. Oh! And don't forget the duplication in setup.py -- you'll want to put your requirements there, too.
- 1f60c 6y agoAs far as I know, Pip doesn't have the notion of dev dependencies, so you need at least two requirements[.dev].txt files.
- dragonwriter 6y ago> 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.
- 1f60c 6y agoD’oh! Thanks. :)
- pas 6y agoThat'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-changes-20-3.html https://pythoninsider.blogspot.com/2020/07/upgrade-pip-20-2-...
- deleted 6y ago[deleted]
- jjoonathan 6y agoBut 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.
- dfee 6y agoI tried to downvote this, but I think it’s already downvoted to the max. There is so much wrong with this pattern. Please use something like Poetry to manage deps.
- paulie_a 6y agoI never have a unified requirements file.
- airstrike 6y agoThat link is a really good read. Better than TFA, tbh. And also particularly well written > An interesting side-effect of PEP 518 trying to introduce a standard file that all projects should (eventually) have is that non-build development tools realized they now had a file where they could put their own configuration. I say this is interesting because originally PEP 518 disallowed this, but people chose to ignore this part of the PEP xD We eventually updated the PEP to allow for this use-case since it became obvious people liked the idea of centralizing configuration data in a single file. Hilarious and indeed interesting
- franciscop 6y agoThis happens often in Node.js where you can put the configuration of some tools (e.g. babel, jest) inside package.json
- kdeldycke 6y agoI love pyproject.toml. I managed to get rid of setup.py, requirements.txt, requirements-dev.txt and MANIFEST.in, and I'm not far from having no setup.cfg soon. All others stuff (CI/CD workflows, linters, formatters, code of conduct, funding, issue and PR automation, dependency bots, ...) moved to .github. Now I have a clean and tidy Python project with a tiny 12-items root directory: https://github.com/kdeldycke/meta-package-manager https://github.com/kdeldycke/meta-package-manager
- tony 6y agoHow conscientious. And yup, conventions like this work well Linux and BSD's. To note ~/.config for many configs These days you see this happening inside of .github/, where configs related to gh repos and actions go. If tooling authors started universally recognizing .config/ as a directory where we could keep stuff, the root could be super clean. How about just one file, across languages / CI tools / etc? a "project.toml" or "project.yaml" or "project.json"? [tool.npm] name = "frontend" version = "1.0.2" [tool.npm.dependencies] react = "^16.3.1" [tool.travis-ci] # ... [tool.eslint] # ... [tool.poetry] name = "backend" [tool.poetry.dependencies] django = "~3.1.0" If vendors were willing to accept it, it'd be less clutter. Integration tools would only need to check one place (legacy configs would still have to be supported, though, so it's still a dream) Legacy configs could be ported via YAML / JSON straight into the TOML sections. It'd work for package.json or tslint.json, but not stuff involving runtime, e.g. .eslintrc.js
- thayne 6y agoI like the idea of a single consolidated config file as long as: 1. It supports real comments (so not json) 2. It supports imports/includes so if it gets unwieldy it can be split up.
- paulie_a 6y agoSplittig it up so you can also determine the environment. I do this with Django settings the time: base/common, local, testing, production. The latter are very tiny and contain small bits of extra configuration. Personally I like this approach way more than a bunch of if/else statements in a single file.
- ksenzee 6y agoOne directory, maybe .config, seems like a good idea. One file is asking for trouble. All it takes is someone writing their first command-line app mixing up > and >> and suddenly the user's config for every tool they use is gone.
- 6y ago
- javajosh 6y agoI mean, for most tools it would be pretty easy to look at .config/ first and then at the project root - and print something about the new best practice. The whole thing is a little uncomfortable though. There is a clear isomorphism between the contents of the structure of, say, a JSON file, and the contents of a directory of structured text files (and other directories). Heck, you could build a little tool with a slider that moves all the data between a single file, and a deep directory hierarchy with lots of tiny text files as the leaves. Personally I feel like the best solution is to somehow "indelibly" combine the tool with its config within a project, de facto removing all config options from the developer. In the worst case, it could be something as silly as a wrapper script with config embedded in there. Of course this is a kind of fiction, but a useful one. It feels nice to get to a point where you don't have to think about tooling. (The last time for me was like 2000).
- akira2501 6y ago> In the worst case, it could be something as silly as a wrapper script with config embedded in there. That's not a terrible idea. For me, I really like tools such as 'nft' that take advantage of the shebang line to solve more or less this exact problem.
- tlb 6y agoIt's probably too late to change every tool. If the main problem is that, when you go look at a project on github or gitlab, you see a long list of config files rather than the code you're looking for, a cleaner solution is for the git sites to show the listing for a /src directory instead of / on the project page.
- deleted 6y ago[deleted]
- gerry_shaw 6y agoOr hide/collapse dotfiles like the ls command does.
- mikepurvis 6y agoPutting them in .config is something to work toward in the long term, but I like this as an immediate fix. A possible UX could be a single entry at the bottom of the repo root listing with "+ 6 hidden files, click here to show", that then expands out to to reveal the full listing when clicked. Edit to add— someone suggests this on the linked issue, and it is mentioned as a concern that auto-hiding the files could lead to them being used to conceal malicious code. Not sure how significant of a concern that really is, but it's an interesting angle, anyway.
- Symbiote 6y agoYou can also hide malicious code by putting it in a subdirectory, so I don't agree with their concern.
- deleted 6y ago[deleted]
- emmelaich 6y agoAlso, please don't use dotfiles. There is no reason to hide such important files.
- smt88 6y agoOn 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.
- tesseract 6y ago`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.
- dylan604 6y agoi much prefer them to be hidden by default. i know they are there, but rarely do i need them. especially in something like `for i in $(ls -1)` type of commands. if i need them `alias 'lla = ls -la'`, 'alias 'la = ls -a'` are faves to now see what i'm looking for quickly
- Symbiote 6y agofor i in *
- milkytron 6y agoI think Windows has them hidden by default as well (in explorer).
- marcosdumay 6y agoSince Win7. But Windows has a lot of problems with hidden files, so a lot of people just set it to not hide any.
- 6y ago
- smt88 6y agoIn 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.
- kahrensdd 6y agoIt 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.
- 29athrowaway 6y agoI also personally think it sucks. Put everything in a folder, and use a namespace, e.g.: org.organization-name.project.json
- dylan604 6y agonamespaces was the thing i was looking for without knowing what it was. it was a very happy day in my world when i was introduced to them.
- anddyyyu 6y agoWho cares. Get over it.
- mantap 6y agoIf everybody had that attitude we'd still be hunting with sticks.
- jeppesen-io 6y agononsense - files in the root of a directory does not stop progress. What an absurd analogy
- jonoc 6y agoI'm guessing it's a tongue and cheek way of saying "why be resistant to change without reason?"
- dylan604 6y agoI'm sure your bosses love you. Boss: Where's the config file? You: In the project root. Boss: Where's the include with the methods for this part? You: Loose in the project root. Boss: Where's the viewer? You: Right next to the other file in the project root. Boss: @#!$%^&
- klyrs 6y agoJust curious, how many icons are on your desktop?
- wqsz7xn 6y agoOn 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.
- benrbray 6y agoDo 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?
- marcosdumay 6y agoNope, he means the "new" LSB preferred directory for user-level configurations. "New" being quoted here because it's around a decade old already.
- LukeShu 6y agoNit: ~/.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.
- ironmagma 6y agoI 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 6y ago[deleted]
- deleted 6y ago[deleted]
- Macha 6y agoThankfully 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 https://wiki.archlinux.org/index.php/XDG_Base_Directory
- jchook 6y agoI find many developers have an aversion to directories containing many files, even if those files semantically “belong there“. I think our tools drive this aversion quite a bit.
- edoceo 6y agoI'm using .config when I find it but for the last 15+ years on new projects, regardless of language I'd been making an `etc` directory and putting config in there.
- dgellow 6y agoI would assume all these tools to support a —-config or —-file parameter to specify where my config is. Couldn’t that be specified in package.json directly? That way you can move your config wherever you want.
- badrabbit 6y agoHow come /usr/etc/ didn't become popular?
- klodolph 6y agoThis is for config files inside a repo.
- dahfizz 6y agoWhat'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?
- kardos 6y agoWe did? https://fedoraproject.org/wiki/Features/UsrMove https://fedoraproject.org/wiki/Features/UsrMove
- sergeykish 6y agoI always wondered why /usr was not abandoned in favor of root > Why don’t you move all /usr contents to / and forget about /usr? > Because this introduces a lot of new toplevel directories, which all have to be mount points then to be shared across other hosts. > Ok, but what about a root filesystem on the network and mounting local filesystems only? > Then you would share the toplevel directory hierarchy among all hosts. Hosts would need to mount /etc and /var for host-only versions. So it is about network boot. Sad. There is nothing "usr" about /usr, it is system installed packages - /sys or /System. And /usr is for "/usr/dmr" which is /home. At least no more /usr/local.
- badrabbit 6y agoI think /etc/ is for system wide config, but I take back my original comment. XDG apparently has a standard for this nobody follows.
- deleted 6y ago[deleted]
- ayroblu 6y agoI 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 hide show toggling or automatic grouping (see macOS desktop stacks) with your fs viewer would be a better area to tackle. Finally, just wanted to say, everything at root level is usually config or a folder, so if I want to understand what tooling a project uses, I know immediately where to go, code is always in a "src" or similar. It sounds like this is a feature, not a bug.
- ralphstodomingo 6y agoLikewise here. I think that as far as defaults go, having these config files accessible in project root so makes it easy for people to see what tooling a project uses. Suppose this pushes through and .config becomes more of a default than a conscious project choice. I don't see all tooling packages to follow-through immediately with it - causing a period where you still have the scourge of some config files in project root, while others are at .config.
- jeppesen-io 6y agoA voice of reason
- mehrdadn 6y ago> 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.
- themarkn 6y ago... “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.
- ocdtrekkie 6y agoI feel like a given tool deserves at best a single item in the root directory. If your tool needs more than one, you should be making a folder. I'd be totally on board with putting all those folders in another folder, but I'm iffy on the indeed the frustration of getting everyone to agree on one.
- sroussey 6y agoThis is a UI problem, not a file location problem. GitHub and VS Code (both M$), could implement a nice way of grouping these files out of the of other files at the tip level.
- jonoc 6y agoThis assumes everyone is using GitHub and VS Code - I think the main issue is applying it to the node ecosystem as a whole
- spanhandler 6y agoOof, I hate it when an IDE/editor tries to "helpfully" present the file tree differently than it actually is.
- FridgeSeal 6y agoLooks pointedly at Visual Studio. Few pieces of development-related software frustrate me more than Visual studio. The seeming disconnect between what's on disk, where on disk it is, and where and how it's displayed in the UI is cavernous. It also outright ignore things that are present in the folder unless you explicitly add it through the interface. God forbid you drop a file in, add it through the UI then move it because you discover you've dropped it into the wrong one of the 3 million nested folders large dotnet projects seem to generate. Changing things on disk underneath it practically gives it an aneurysm. VSCode and IntelliJ IDE's handle the same situations without panicking, so why is VS so fragile?
- overgard 6y agoI think it's because of C++ in large part. For whatever reason there's been weird conventions in different code bases on how to structure headers vs source (like, put them in the same dir, or have an "includes" and "src" dir that mirror each other, or have an includes dir that doesnt match the src dir at all. Not defending it because it sucks, but I think .NET just inherited that weird interface because its what C++ did.
- 6y ago
- hakcermani 6y agoRather than a .config/ folder how bout a .tooling/ folder ... as it is for the tooling. Projects usually have a config dir for server / environment configs. Would be easy to confuse the .config/ of tooling with the config/ for the app itself
- tengbretson 6y agoThe 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.
- deleted 6y ago[deleted]
- jjoonathan 6y agoSystemd pokes its head around the corner. Build tools? Its stomach rumbles. The beast hungers.
- coredog64 6y agoSo my project will have var/run/.build-unit?
- jolux 6y agoI 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.
- dfee 6y agoJavaScript isn’t the hero we wanted, but TypeScript is the hero we need.
- desert_boi 6y agowith ESLint and Prettier on top.
- slimsag 6y agoalso don't forget: - .eslintrc.json to configure ESLint - .prettierignore because it tries to format package-lock.json - prettier.config.json - npm/yarn and package.json + node_modules - .nvmrc to pin your node version - storybook - renovate to update dependencies - .editorconfig to ignore node_modules - mocha for testing and .mochaarc.js - stylelint and .stylelintrc.json + .stylelintignore And maybe throw in Jest, tsconfig.json, a gulpfile, and some other stuff.
- cesarb 6y agoThe suggestion in the thread to "support defining this in package.json" (https://github.com/nodejs/tooling/issues/79#issuecomment-664471262 https://github.com/nodejs/tooling/issues/79#issuecomment-664...) reminded me of autoconf. It also has the issue of lots of auxiliary files in the project root (but worse since they're not hidden files), and the solution there is that you can add "AC_CONFIG_AUX_DIR(aux)" to the configure.ac to make it look for these auxiliary files in the "aux" subdirectory instead of the project root (for instance, "aux/config.guess" instead of "config.guess").
- q3k 6y agoTo me this is part of a larger problem: tools that expect a given directory layout, or even worse, that they are the sole tenant of a given repository. Just because my project contains some node.js code doesn't mean that I want to have a top-level, global node_modules directory. Let me organize my repository files however I want and however best fits my project organization.
- _ZeD_ 6y agoNo please. Standardization is the key. You (not you!) Don't know how to organize your project, and I don't want to know where are the config in each project I work on
- reillyse 6y agothis is the solution :) ... I miss rails where everyone knew where everything was supposed to go, a little like how much I love prettier now - no more stupid bike shedding conversations about coding style.
- sneak 6y agoThe 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).
- Symbiote 6y agoAnother option would be for Github etc to sort dotfiles to the bottom of the listing.
- DivisionSol 6y agoThis 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.
- Trisell 6y agoI don’t find it a scourge. I actually find that I can look quickly at a project and get an idea of the tools that they are using. This seems to be a bonus and really a few more files isn’t a big deal.
- johnwalkr 6y agoFully 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.
- deleted 6y ago[deleted]
- didip 6y agoThis is a non-issue, thus no need for a solution. If you have too many config files, then you should use less tools. Besides, most of them are already hidden anyway (because of dotfiles).
- Polylactic_acid 6y agoHidden files are never hidden to developers because they need to be accessed and changed so often.
- deleted 6y ago[deleted]
- silviogutierrez 6y agoI think ultimately it comes down to personalities. I'm the kind of person that likes directories and folders. And having top level files feels clunky and disorganized. Like much organization, taken to the extreme it can be a form of procrastination to avoid doing real work. Yak shaving, if you will. But opening the root project folder to just a list of subfolders gives me a very nice first impression. Below is my list of config files for https://www.joyapp.com https://www.joyapp.com (Django + NodeJS). Not a hugely complex architecture, mind you. Some notes: .editorconfig at least tries to consolidate this for some things. And pyproject.toml could help with Python. Still, definitely jarring and something I've noticed. .coveragerc .dockerignore .editorconfig .flake8 .gitattributes .gitignore .isort.cfg .prettierrc .shellcheckrc jest.config.js mypy.ini package.json pytest.ini requirements.txt shell.nix tsconfig.json tslint.json webpack.config.ts yarn.lock
- sethammons 6y agoI'm not a node dev, but our projects at work keep growing with helper files. We have a .buildkite to control the build, we have a makefile, a Dockerfile, a docker-compose file, go.mod and go.sum. These core files are about half of what we had a few years ago, so that is nice. The makefile references a dozen helper scripts though that are also checked into the repo (helpers to run tests, build images, publish images, clean up, etc). Most of these are vastly similar between different repos/services we run. I can't think of something better, and there is a part of me that enjoys the lack of magic: just follow the code starting at ./buildkite which will point to each make operation which will point to each helper script. The other part of me feels like, "I just want to write some code and as long as my project is structured right, everything else should be shared tooling _outside_ my repo."
- smitty1e 6y agoI put my noise in an etc/ subdirectory.
- scrose 6y agoThe Rails community attempted to do something like this with the introduction of Webpacker in Rails 5. They backtracked after a few months. Most likely after realizing how many thousands of npm packages make tightly coupled assumptions to the location of things like ‘package.json’ and the amount of patches it would require.
- thenanyu 6y agoThis is fine. It's practical, but a little ugly. Same discussion that we had the other day with Tailwind CSS. It's fine, it's very practical, but a little ugly.
- throw_m239339 6y agoThe 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.
- hnzix 6y agoNow 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?
- rndgermandude 6y ago*gRPC ;)
- chii 6y agojavascript ecosystem is just slowly (and badly) reinventing all of the "enterprise" features that they claim to hate about java!
- deleted 6y ago[deleted]
- Izkata 6y agoEhh, this is just moving the mess from one location to another. All these config files can be grouped into two or three conceptual things: * Dependencies - Things required for your code to run, for example Dockerfile, package.json, yarn.lock * Metrics - Measuring code quality, but the project works without these, such as jest.config.js, .eslintrc, .eslintignore * Other - I don't recognize several config files here, and suspect some don't fall into the categories above, but am not sure. Also, README.md and .gitignore would fall into this category, but probably ought to remain at the top. So instead of a generic "configs/" directory, if I was to organize these myself, I'd probably want at least two subdirectories so it would, y'know, actually be a bit more organized.
- nautilus12 6y agoI feel like the is just unecessary OCD behavior. We get enough of that in software already
- bfred_it 6y agoThere’s a solution to this problem: https://github.com/sindresorhus/hide-files-on-github https://github.com/sindresorhus/hide-files-on-github Additionally, your OS probably already natively hides files that start with a dot, so this is just a UI problem. Please don’t “solve” this issue by moving files to a sub-directory. If anything, only leave non-config files there, it’s the obvious simple solution that most projects follow anyway.
- CivBase 6y agoIt's not a scourge. It's a sensible default location. Most tools let you explicitely specify a config file path if you want to store it elsewhere.
- neurostimulant 6y agoMy head hurt thinking about how much efforts and coordination across multiple ecosystems required to pull it off. And if they do manage to pull it off, the reward is... slightly cleaner project top directory?
- brabel 6y agoI like how Gradle works. Basically, if you want to add a new "tool" to your project, you add it as a plugin in `build.gradle`: plugins { id "com.github.spotbugs" version "4.5.0" } Then, in the same file, you configure it: spotbugs { visitors = [ 'FindSqlInjection', 'SwitchFallthrough' ] // more config } Some plugins require external files, but that's usually because the plugin was not designed for Gradle and/or the authors didn't bother to add some code in their plugins to read config from the project file (which is usually very easy).
- juped 6y agoThe great thing about all these config files is as a barometer for the popularity of various bad flavor-of-the-month config file formats reinventing key=value.
- mbar84 6y agoA nice convention in python projects is that you can use setup.cfg or pyproject.toml for many tools and they each just use their particular section.
- MrQuincle 6y agoInteresting discussion. If it's about "cleaning up" before committing, a single script that moves files back and forth from project root to a .config path might also be an option...
- skocznymroczny 6y agoI think a good fix would be hiding dotfiles on repository view like on GitHub. "ls" hides dotfiles from you by default, so why shouldn't GitHub. You can always add a checkbox "Show hidden files" or instead of completely hiding them put them in an accordion (12 hidden files) that people can click to reveal them.
- devin 6y agoWho cares? The obsession with hierarchy is silly. Good search beats hierarchy.
- lolsal 6y agoNot if you don't know what you're looking for (i.e. just browsing).
- rswail 6y agoI'm not sure why this [1] pattern can't be adopted/extended. Put everything in a .config directory. Search path for config is: * /etc/config * $XDG_CONFIG_HOME (~/.config) * $PROJECT_CONFIG ($PROJECT_ROOT/.config) * directories between $PROJECT_ROOT and $CWD for .config * $CWD/.config This allows for system wide, then user wide, then project wide, then directory hierarchy configs, with lower levels overriding higher ones. Inside .config, each tool can have it's own chosen file, directory, extensions directory, so: .config/$TOOL.{json,yaml,toml,ini,xyz} .config/$TOOL/config.ext .config/$TOOL.d/modular config files eg 00-module.ext Most of the time for most projects, there will be system wide and user wide config, then a project wide config. Overrides lower in the hierarchy tend to be less used. Yes, it means that there's a tree search for a tool to get its final config. Whether that's a real issue for performance or otherwise is a potential to remove some of the hierarchy/search. [1] https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html https://specifications.freedesktop.org/basedir-spec/basedir-...
- gumby 6y agoThis is not what unexpected! To me the scourge is tool config files being in the repo at all. Ok I’ll make an exception for .gitignore or something that enforces house style or formatting conventions to make things proper for check in. But an editor config? That’s so user-specific and shouldn’t affect (or should I say “infect”) the source code.
- iainmerrick 6y agoThe .editorconfig specifies things like tabs vs spaces and the indent size. Everybody needs to use the same settings to avoid messing up the formatting every time they edit a file. Therefore, .editorconfig gets checked in so that everybody gets the same settings.
- tylerjwilk00 6y agoSimple. Add a new config to the project root directory that defines the config locations. Done. /jk I do like the .config directory naming suggestion though.
- peterwwillis 6y agoIf the organization of files in your repo is your biggest problem, you've obviously got excellent code and no tech debt. In which case you probably have enough free time to build a tool that just moves files around at runtime. Organize your repo however you want, then run your tool as a wrapper for any other command, and it'll move all files into the places other tools expect them. Now you've solved the problem, which was that humans like aesthetically pleasing things that serve no useful purpose.
- LoSboccacc 6y agowhat'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
- deleted 6y ago[deleted]
- chmod775 6y agoThis is a problem mainly for people who use GUIs. When you use a terminal you don't really care how many files are in a directory, unless they have names that are annoying to autocomplete.
- epistasis 6y agoIf that were the case, why would we bother separating out code into multiple directories at all? The reason we bother with modules and directories is to help organize code and ease discovery. And whether we use ls or a GUI, we all start out the process of discovery with a directory listing. The top-level directory, where these files are, is often where there's the most flexibility in terms of how to lay out things. All this clutter hides the project organization and makes it difficult to discover what's going on. It was one thing when it was just autotools, but the proliferation of tools in the last decade has brought it over a tipping point, IMHO.
- chmod775 6y ago>If that were the case It is the case: They don't bother me when I'm using a CLI, but when I use Visual Studio Code for instance, all those files are annoying when I'm looking for something/scrolling past them.
- mcovey 6y agoThis is not a new problem. You should see my home folder. I hardly ever look at it, I moved into ~/Downloads since at least I can keep that tidy myself.