Stow powered, convention first, dotfiles for different platforms and environments.
Branch: master
Clone or download
Pull request Compare This branch is 67 commits ahead, 48 commits behind Kraymer:master.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
@linux
@osx
_dpkg
_homebrew
_pip
_safari
android
attic
bat
cheat
clang-format
coreutils
ctags
diff
docker-machine
dokku
exenv
flutter/.zsh
git
golang/@home/.zsh
gpg
htop
input
ios
jboss
linuxbrew
mutt
nano
ncdu
nodenv
perl
pip
prettyping
pyenv
rbenv
rust
snap
stow
taskwarrior
thefuck/.zsh
tmux
tmuxinator
tmuxp/.tmuxp
vim
weechat
xml
zsh
.gitignore
README.md

README.md

These dotfiles are forked from F-dotfiles which is an opiniated dotfiles organization scheme based on stow.

Highest priorities are ease of maintenance and deployment on both Linux and OS X.*

  • stow powered: symlink dotfiles and thus keep them always up-to-date in your repository
  • topical organization: organize dotfiles by application facilitating reuse across different machines
  • clever naming scheme: the repository architecture is easy to browse while staying compatible with stow symlinking mechanism
  • KISS: there is deliberately no build script involved at all, the repository consist of dotfiles all installable using same modus operandi (stow <directory>)
  • documentation: each package has a README.md which present its purpose and a flat tree view of its files. Install notes and requirements can also be listed.

Install

  1. clone the repository : git clone https://github.com/ryjen/dotfiles ~/ ; cd ~/dotfiles
  2. setup stow, inception style : stow -t ~ @home or stow -t ~ @work or an environment of your creation 
  3. install desired package via stow <directory> 1

When needed, special install instructions are present in package README.md file.

Rules

Walter - The rules really tie the repo together, do they not?

Directories naming

  • lowercase for packages to install in $HOME (the default)
  • titlecase for packages to install as root in /, eg @Daemon-osx
  • leading @ for environment packages and subpackages, eg @mac, attic/@Daemon-osx
  • leading _ for non packages, eg _homebrew meaning that these directories must not be stowed

Having a convention for subpackage naming enable us to write a .stow-global-ignore file so that subpackages are not symlinked when stowing parent package.

Ignore files

Quoting stow documentation :

if Stow can create a single symlink that points to an entire subtree within the package tree, it will choose to do that rather than create a directory in the target tree and populate it with symlinks.

.gitignore can be present in packages because of this behaviour, in order to avoid having your repository cluttered with unknown files, see example.

Secret files

Secret files, ie files that should not be commited/published, must have .sec or /sec/ in their filepath to be ignored by the root .gitignore file. Each secret file should be accompagnied by an .example file that is commited instead, to illustrate the use.

Keep your secret files as short as possible to limit their influence as it complicates deployments (as they cannot be just pulled from github).

See example.

Multi-platforms paths

Where to save a file that is installed at different locations depending on the OS ?

The trick is to have one package per OS, just to create each specific directories structure properly. Then create the part of the filepath that is common to the two OS in <package>/_common, put the files in it, symlink from the subpackages to that location.

Feel confused ? Check example


1 it's because we installed stow package at step 2 that the flag -t ~ can be omitted here, see .stowrc
2 https://www.youtube.com/watch?v=ezQLP1dj_t8