Crates.io | dull-dotfile-manager |
lib.rs | dull-dotfile-manager |
version | 0.1.1 |
source | src |
created_at | 2023-11-19 12:13:41.756062 |
updated_at | 2023-11-19 19:09:20.5258 |
description | A dull dotfile manager |
homepage | https://github.com/utkn/dull |
repository | https://github.com/utkn/dull |
max_upload_size | |
id | 1041129 |
size | 499,081 |
A dull dotfile manager
Clone this repository, cd
into it and invoke cargo
to build and install it for you:
$ cargo install --path .
Create a new folder. The goal is to set up dull
such that all your dotfiles can be managed from here.
Create a configuration file config.toml
at the root. The configuration file should contain module
s that map a source
path to a target
path. In this example, we will assume that we want to manage three configurations (i.e., alacritty
, helix
, and fish
) and have the following folder structure:
.
├── config.toml
└── modules
├── alacritty
│ └── alacritty.yml
├── fish
│ ├── config.fish
│ ├── fish_variables
│ └── functions
│ └── fish_prompt.fish
└── helix
├── config.toml
└── themes
└── custom.toml
Accordingly, the configuration file config.toml
might contain the following:
# config.toml
[[module]]
source = "modules/alacritty"
target = "~/.config/alacritty"
[[module]]
source = "modules/fish"
target = "~/.config/fish"
[[module]]
source = "modules/helix"
target = "~/.config/helix"
First, we build the system:
$ dull build
This creates a virtual filesystem under the folder ./builds
. The build will fail if there are conflicting modules.
Then, we deploy the latest build:
$ dull deploy
This creates symlinks in the target directories (e.g., ~/.config/alacritty/alacritty.yml
will point to ./modules/alacritty/alacritty.yml
) which allows the user to manage their configurations from a single directory, allowing them to be easily maintained with version control like git
.
Note that the deployment will fail if the module targets are not empty. In order to deploy by removing old files/directories, use the --force
flag. This is not advised, as this is a destructive operation.
Alternatively, you can perform a hard deploy which directly copies the files from the modules to their target paths:
$ dull deploy --hard
This makes sense when you want to remove dull
from your system.
To remove the deployed files, invoke:
$ dull undeploy
This clears the module targets for the latest build.
It is possible to deploy and undeploy particular builds using the --build
flag.
By default, dull build
recursively traverses the module folders and considers only the files included in the module directories as its linking sources. You can set directives to selectively link folders instead of files. There are two possible directives: linkthis
, and linkthese
.
A linkthis
directive can be added by creating a .dull-linkthis
file under a folder in one of your modules. The folder containing this marker file will be linked directly. Similarly, a linkthis
directive can be added by creating a .dull-linkthese
file. All the files and folders that are in the same directory with this marker file will be linked directly.
These directives can alternatively be specified in the configuration file, instead of creating marker files as described above.
Deployments are atomic. In other words, if something unexpected happens during the process, dull
tries to rollback the filesystem to its original state. This adds significant overhead but minimizes the risk of accidentally destroying your system.
This documentation is incomplete. To learn more about possible commands and flags, invoke:
$ dull help