Live data from Hacker News

Tips on how to structure your home directory (2023)

unixdigest.com

51–60 of 172 posts

Re: Tips on how to structure your home directory (2023)

#51
post #35

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most is the default directory for go modules `~/go`. This frustrates me so much. I refused to install any go apps or use it for development for years. I've unfortunately had to give in, and it can at least be overridden by setting `GOPATH`, but it is a terrible, te…

I wish more developers would seek out and embrace libraries for saving things in sensible locations. Python has one called “platformdirs” that takes the guesswork out of where to save things automatically for the user’s platform. I have no doubt all the other major environments have something similar.

If you ask me, this should all be built-in, but even then (because on many platforms, it is), people can’t help rolling their own.

Standards XKCD I guess.

Re: Tips on how to structure your home directory (2023)

#52
In case anyone is looking for inspiration, my macOS homedir contains:

  # multiple organizations under Projects:
  ~/Projects/GitHub-org-name/repo-name

  # temp files:
  ~/Scratch/0_jira
  ~/Scratch/1_temp
  ~/Scratch/2_builds
  ~/Scratch/9_archive

  # Emacs org-mode files
  ~/Org

  # Top-level screenshots
  ~/Screenshots
Using it with zoxide[1] allows me to run "z weba" and get taken to:

  ~/Projects/client_org/amazing-webapp
I also use a couple of helper functions in my zshrc while working in the Scratch directories:

  # Marky Mark and the Function Bunch
  function gcd {
    git clone $1 && cd "$(basename "$_" .git)"
  }

  function showpath {
    echo $PATH | sed -e $'s/:/\\\n/g'
  }

  if [[ $OSTYPE =~ ^darwin.* ]] then
    function brewup {
      brew update && brew upgrade && brew cleanup
    }
  fi

  function mc {
    command mkdir $1 && cd $1
  }

  function mcd {
    local TODAYDATE
    TODAYDATE=$(date +%F)
    command mkdir ${TODAYDATE} && cd ${TODAYDATE}
  }

  function mce {
    command mkdir ${EPOCHSECONDS} && cd ${EPOCHSECONDS}
  }
EPOCHSECONDS comes from the zsh/datetime module[2]

[1] https://github.com/ajeetdsouza/zoxide

[2] https://zsh.sourceforge.io/Doc/Release/Zsh-Modules.html#The-...

Re: Tips on how to structure your home directory (2023)

#53
post #44
post #35

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most is the default directory for go modules `~/go`. This frustrates me so much. I refused to install any go apps or use it for development for years. I've unfortunately had to give in, and it can at least be overridden by setting `GOPATH`, but it is a terrible, te…

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

Counterpoint:

I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in.

I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `Android/android-studio` for Android Studio, `intel` for IPP/OpenAPI, etc.

Don't want it anymore? Easy rm -rf, no need to go digging for where it could be hidden.

Re: Tips on how to structure your home directory (2023)

#54
post #49
post #35

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most is the default directory for go modules `~/go`. This frustrates me so much. I refused to install any go apps or use it for development for years. I've unfortunately had to give in, and it can at least be overridden by setting `GOPATH`, but it is a terrible, te…

Pro tip: don't put your stuff in your $HOME directory. $HOME is for applications to pollute. Put your stuff literally anywhere else.

$HOME is where my terminal and file manager start. It's not reasonable to give up on this prime directory real estate.

Re: Tips on how to structure your home directory (2023)

#55
post #50

I actually have quite a simple structure that serves me well (your mileage might vary) projects/ 2023/ 2024/ 0000-something/ 0312-other-project/ 0419-hn-comment/ each year I make a year folder. And each project has a month + day prefix. Sometimes I want long term projects to pop up on top, so I prefix them with 0000 (or only make the day 00). It is simple, works on any OS. Although on Linux I do have some helper scri…

Why not use folder dates for that? It could be sorted.

  projects/           | 01.01.2017
    something/        | 01.01.2024
    other-project/    | 01.01.2023
    hn-comment/       | 01.01.2022

Re: Tips on how to structure your home directory (2023)

#56
post #45
post #35

I hate having a polluted home directory, especially when an application thinks it should get a non hidden directory in my home! The one that upsets me the most is the default directory for go modules `~/go`. This frustrates me so much. I refused to install any go apps or use it for development for years. I've unfortunately had to give in, and it can at least be overridden by setting `GOPATH`, but it is a terrible, te…

IMO, the GOPATH itself is a terrible design. It makes you mix together things from unrelated projects in the same directory structure, instead of each project having its own independent directory structure, like on every other programming language. The GOPATH design goes so much against the way I organize my projects, that it's the main reason I have never got interested into learning Go. Perhaps this design makes mo…

This hasn't been the case since go modules exist, if I understand your issue correctly: https://go.dev/blog/using-go-modules. You can additionally vendor each project's dependencies

Re: Tips on how to structure your home directory (2023)

#57
post #46
post #45

Earlier quoted context omitted.

IMO, the GOPATH itself is a terrible design. It makes you mix together things from unrelated projects in the same directory structure, instead of each project having its own independent directory structure, like on every other programming language. The GOPATH design goes so much against the way I organize my projects, that it's the main reason I have never got interested into learning Go. Perhaps this design makes mo…

GOPATH actually made me realize that the ~/src/$host/$owner/$repo organization structure makes a ton of sense for every project and as long as you organize all of your languages into this one tree, everything just works.

Can you expand on this a bit please? What does $host mean? Why would I need that for a purely local project that is only created for my own use? And what about grouping projects? E.g. "personal", "work", etc. And where in the structure are languages? Is that the overarching directory?

Re: Tips on how to structure your home directory (2023)

#58
post #53
post #44

Earlier quoted context omitted.

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive. Counterpoint: I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in. I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `And…

In theory, all applications following XDG would also solve the problem, as it has only 1 configuration directory. (Although I admit some apps use the data directory which brings it up to 2)

Re: Tips on how to structure your home directory (2023)

#59
post #53
post #44

Earlier quoted context omitted.

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive. Counterpoint: I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in. I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `And…

The point of XDG is to take the guesswork out of it by having applications follow your stated preferences.

Re: Tips on how to structure your home directory (2023)

#60
post #53
post #44

Earlier quoted context omitted.

The worst offenders are CLI tools written by people on Macs that do not respect XDG, because it's not a thing over there. So every tool gets to pollute your dotfiles with its own stupid directory. .rustup, .mix, .npm, .yarn, etc. But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive.

>But polluting your home directory like ~/go, without even the decency to hide it, is extremely rude and offensive. Counterpoint: I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in. I got used to it and in HOME I put some of my manually installed tools like `AMD_AOCL` for the AMD AOCL libraries, `And…

  "I actually like having visible directories, versus having to figure out where in /usr/share or /usr/local/ or ~/.local or /var an installer chose to sneak their files in."
You seem to be mixing together two concepts here:

1. The files created by the installer, which are handled by the package manager. I can consult my package manager for files created by a specific package: pacman -Ql package_name.

2. The files created after installation (user preferences, plugins). The program should follow the XDG specification.

Post reply on HN