Warning, I’m about to get on my mild OCD soapbox again. Too many development tools expect to get the privilege of a config file in the root directory of my projects. Many of them don’t even allow it to be a hidden file—they just require a fully unhidden “tool.yml” file sitting right there in the root of your project. Stop it. Please. Linux HOME Directory Link to heading Once upon a time this was a serious problem for organizing files in the Linux HOME directory too. Tools thought way too much of themselves and added files, directories, etc. to your HOME folder. A lot of them still do!
    • ulterno@programming.devBannedEnglish
      10·
      11 months ago

      Yeah, everyone (every-app) thinks they are special and deserve a “.place” in ~ because : <enter their reason>.

      • ssh because “I’m SSH!”, similar for gpg
      • npm because “I’m a package manager”
      • dillo because “I am old and can’t be bothered to update my dirs”
        • I guess I should send them a patch. It shouldn’t be too hard to make that little change.
      • fltk same as dillo maybe
      • .mozilla : “Oh but I AM special”
      • .bundle : There is literally only 1 subdir in it and it is named “cache”. they could have just done “~/.cache/bundle” instead

      IDK why you have a .kde in your screenshot. Debian maybe, or a dir remaining from KDE4? I had an old one remaining in Debain after I upgraded.

      • .config
      • .local
      • .cache

      These are what we need to stuff everything into.

      • Samueru_sama@programming.devEnglish
        12·
        11 months ago

        .mozilla : “Oh but I AM special”

        You would think that thunderbird would use ~/.mozilla as well but nope. It is ~/.thunderbird 🤣

    • EpicStuff@lemmy.caEnglish
      2·
      11 months ago

      I tried to “fix” this using xdg-ninja but then gave up and resorted to just creating a .home in ~ then running usermod -d ~/.home. Then I just symlinked my documents and .config and etc. folders to my “real” home.

  • qaz@lemmy.worldEnglish
    23·
    11 months ago

    I made a tool for this some time ago. It detects when programs write to your home directory outside the XDG spec and logs the file and the location of the binary that wrote it to an SQLite file.

  • paequ2@lemmy.todayEnglish
    10·
    11 months ago

    Many of them don’t even allow it to be a hidden file—they just require a fully unhidden “tool.yml” file sitting right there in the root of your project.

    I love this. I hate when tools only allow hidden config files. I want to know where the config is—my teammates should be aware of where the config is. I don’t want to be tricked into thinking there isn’t a config file in a directory.

    I actually have alias ls='ls -A' in my bashrc so I see everything.

  • Eager Eagle@lemmy.worldEnglish
    8·
    11 months ago

    yeah, I’ve also been noticing this in the past months. The number of dotfiles in project roots is an ever growing number, to the point where we have literally dozens of files and directories and only a handful that actually mean anything to the project. It’s pure clutter.

  • esa@discuss.tchncs.de
    4·
    11 months ago

    We could probably stand to have some organisation standards in repo roots, but I tend to agree that dotfiles aren’t the way to go there. The project root is similar to ~/.config and the like: When you’re there you should not be subjected to further hidden levels. Those config files are a significant part of the project.

    State files however, like all the stuff in .git, lockfiles and the like are generally¹ fine to hide away. Those are side effects of running other tools, not ordinary editable configuration. Same goes for cache—and both cache and runtime files should likely go in the ordinary XDG dirs rather than be something every project has to set up a gitignore for.

    If anything I’m more frustrated with the C projects that just plop every source file in the root directory.

    ¹ Just don’t make it too easy to sneak unexpected crap in there. We don’t need to make the next Jia Tan’s job easier.

  • Ephera@lemmy.mlEnglish
    3·
    11 months ago

    Yep, the repository root. Where everyone starts to read your code, so you put your README there and the docs-folder and the entrypoint to your source tree, oh and also all this random guff that no sane reader would ever be interested in.

    I still remember how I tried to read larger repositories for the first time and this was genuinely a hurdle, because I figured these files must be highly relevant for understanding the code.

    My attempt at combating that has been to move as much of the code structure to the top as possible, so that someone new will have a much higher chance of clicking on something relevant. But yeah, downside is that your code structure isn’t as separated from the guff anymore…

    • Eager Eagle@lemmy.worldEnglish
      13·
      11 months ago

      move as much of the code structure to the top as possible

      I do the opposite and move all source code to a generic named src or similar, because the alternative creates even more clutter in the root dir IMO by mixing relevant and irrelevant files. And generic names like src, docs, and tests help keeping a similar structure for different repos.

  • Corbin@programming.devEnglish
    2·
    11 months ago

    My $HOME is recreated on boot and lives in RAM. I don’t care what gets written there; if I didn’t know about it and intend to save it to disk, then it won’t be saved. It would be nice if tools were not offenders here, but that doesn’t mean that we can’t defend ourselves somewhat.