4 ms·

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 maint

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

tomc1985 6y ago
Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files
- rapnie 6y ago
  So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.
  - addicted 6y ago
    How about an all in one config file? You have a standard JSON config file “.config.json” that resides in the root folder with a global object, with each key containing the config for each tool. Collisions might be a concern, but you could use the tool’s url as the key so it’s unique. You are already seeing runtimes like Deno and Go do that for importing source code. Couldn’t the same thing apply for this config file as well?
    - alephu5 6y ago
      That's how I configure my projects using dhall. I'm working on a web application at the moment with a REST API, database, rabbitMQ, a few python workers, nginx, 2 react projects and a Gatsby project plus some docker composes for testing. Everything is configured in the root file and then this is imported into smaller dhall files in the subprojects. In the build scripts I generate all the yaml and JSON from these, even the docker-composes and it's very ergonomic.
      - GenKali 6y ago
        First I'm hearing of this tool and it seems really nice. Do you perhaps have an open repo that shows how you are using the dhall files? If I can reduce my config files to dhall + justfile I'd be quite happy.
    - bryanrasmussen 6y ago
      I'm pretty sure that I've read an aphorism along the lines that every configuration over time develops into an ad hoc programming language (similar to Greenspun's 10th rule so maybe I am just misremembering https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) At any rate the closest I could find to this saying was this HN post https://news.ycombinator.com/item?id=8092967 https://news.ycombinator.com/item?id=8092967 "Configuration files suck. Just use a programming language" >but you could use the tool’s url as the key so it’s unique. reminds me of XML namespaces. on edit: formatting
    - hakre 6y ago
      Not so sure if it "must" be _one_ config file. I also don't think that the format matters more than it's use. Reminds me of some good advice in The Pragmatic Programmer, should be (simple) text-files for editing and (regardless if one or multiple files), a single source of truth (e.g. if multiple files, not the same time the same data to edit in). This is roughly as I remember it and I found it always useful to apply. If I see duplication, it's about fighting the rot and remove it. If configuration files are generated, they don't belong under version control (there are some exclusions to this rule, e.g. pinning dependency versions for example when shared with the repository).
    - rumanator 6y ago
      > How about an all in one config file? What an awful idea. I don't even know where to start enumerating the problems that this approach creates, and what for? I mean, just think about it. Have you ever had to comb through a config file to add support for something but while you were not sure what option dictated which and what impact this or that option had because documentation is ineffective or awful or even non-existent? Now multiply that complexity by all the options added by all the tools expected to use a file, compounded by the fact that God knows how many tools also write to that file and may or may not stay in their lane when doing so. Who in the hell wants to deal with that mess? And what for? Just because someone wants to adopt a tool but has a problem with having to configure its own config file?
  - rumanator 6y ago
    >So are you advising developers to use less tools, or maybe all-in-one toolsets? No, you're the only one arriving at that conclusion. The whole point is that if you're going to adopt tooling then you'll need to configure them all, and that's fine with config files in the project root tree.
  - tomc1985 6y ago
    Yes, less tools. Perhaps by making better use of existing tools
smohare 6y ago
The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess. I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.
- wombatpm 6y ago
  With 3.8 python has PYthoncacheprefix where you can specify where the pyc files end up. Makes life so much better with docker
- Legogris 6y ago
  > The same argument is made for not adhering to the XDG spec for user configuration files I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory. In a software repo, anything inside it belongs to the project.
  - pm215 6y ago
    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?
    - pas 6y ago
      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.
      - 6y ago
dkdk8283 6y ago
I’ve never had a problem using find and grep -R

tomc1985 6y ago

Exactly... the problem isn't the proliferation of config files, it's the use of so many tools that require those config files

rapnie 6y ago
So are you advising developers to use less tools, or maybe all-in-one toolsets? Presumably tools are used to support tasks that were otherwise more onerous and time-consuming and maybe neglected because of that.
- addicted 6y ago
  How about an all in one config file? You have a standard JSON config file “.config.json” that resides in the root folder with a global object, with each key containing the config for each tool. Collisions might be a concern, but you could use the tool’s url as the key so it’s unique. You are already seeing runtimes like Deno and Go do that for importing source code. Couldn’t the same thing apply for this config file as well?
  - alephu5 6y ago
    That's how I configure my projects using dhall. I'm working on a web application at the moment with a REST API, database, rabbitMQ, a few python workers, nginx, 2 react projects and a Gatsby project plus some docker composes for testing. Everything is configured in the root file and then this is imported into smaller dhall files in the subprojects. In the build scripts I generate all the yaml and JSON from these, even the docker-composes and it's very ergonomic.
    - GenKali 6y ago
      First I'm hearing of this tool and it seems really nice. Do you perhaps have an open repo that shows how you are using the dhall files? If I can reduce my config files to dhall + justfile I'd be quite happy.
  - bryanrasmussen 6y ago
    I'm pretty sure that I've read an aphorism along the lines that every configuration over time develops into an ad hoc programming language (similar to Greenspun's 10th rule so maybe I am just misremembering https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule) At any rate the closest I could find to this saying was this HN post https://news.ycombinator.com/item?id=8092967 https://news.ycombinator.com/item?id=8092967 "Configuration files suck. Just use a programming language" >but you could use the tool’s url as the key so it’s unique. reminds me of XML namespaces. on edit: formatting
  - hakre 6y ago
    Not so sure if it "must" be _one_ config file. I also don't think that the format matters more than it's use. Reminds me of some good advice in The Pragmatic Programmer, should be (simple) text-files for editing and (regardless if one or multiple files), a single source of truth (e.g. if multiple files, not the same time the same data to edit in). This is roughly as I remember it and I found it always useful to apply. If I see duplication, it's about fighting the rot and remove it. If configuration files are generated, they don't belong under version control (there are some exclusions to this rule, e.g. pinning dependency versions for example when shared with the repository).
  - rumanator 6y ago
    > How about an all in one config file? What an awful idea. I don't even know where to start enumerating the problems that this approach creates, and what for? I mean, just think about it. Have you ever had to comb through a config file to add support for something but while you were not sure what option dictated which and what impact this or that option had because documentation is ineffective or awful or even non-existent? Now multiply that complexity by all the options added by all the tools expected to use a file, compounded by the fact that God knows how many tools also write to that file and may or may not stay in their lane when doing so. Who in the hell wants to deal with that mess? And what for? Just because someone wants to adopt a tool but has a problem with having to configure its own config file?
- rumanator 6y ago
  >So are you advising developers to use less tools, or maybe all-in-one toolsets? No, you're the only one arriving at that conclusion. The whole point is that if you're going to adopt tooling then you'll need to configure them all, and that's fine with config files in the project root tree.
- tomc1985 6y ago
  Yes, less tools. Perhaps by making better use of existing tools

smohare 6y ago

The same argument is made for not adhering to the XDG spec for user configuration files. The result is you have no real sense of specific locations for config files, shared static data, and app-generated data. If an app follows the spec you know exactly where to look. Otherwise it’s anyone’s guess. I’ll admit this is less of a problem in project dirs, since tooling usually confines itself to a single file. But tooling outputs often similarly pollute. For example, I wish Python dumped its artifacts in a single directory I could delete, instead of in every source subdir.

wombatpm 6y ago
With 3.8 python has PYthoncacheprefix where you can specify where the pyc files end up. Makes life so much better with docker
Legogris 6y ago
> The same argument is made for not adhering to the XDG spec for user configuration files I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory. In a software repo, anything inside it belongs to the project.
- pm215 6y ago
  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?
  - pas 6y ago
    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.
    - 6y ago

dkdk8283 6y ago

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