[Feature Request]: Make All core files modular as posible

[kRHYME7]

Feature Request

Note

"dots" in this discussion means files that are under a dependecny.
a package of configuration that is specific to a single thing
eg all waybar configs ONLY stored as a separate package, we call it dots

Description

Dotfiles are prone for breakage. So we can't version them like we version a single entity/application. It won't make sense (unless nix) Versioning a whole dotfiles repo is messy as the dependecies are not dependent on each other. (we are not a DE)

This approach at least let us version each "dots". Making them modular.
Oh dunst breaks? We fixed it upstream! Update dunst and udpate this "dots" for dunst.

Use Case

• installing/updating dotfiles per "dots"
• Easier install script as we can just select the "dots" that are available.
• themes can use this to describe how to download the theme

Proposed Solution

• should be simple
• Declare the manifest file somwhere, it will be structured to pull the files from a repo

Alternatives

Be a distro, and ship your own dots lol

[richen604]

one method would be utilizing gnu stow / symlinks and sub manifest toml/yaml files
looking at other dotfiles it seems symlinks is the most common method, and stow is a well known system in the space

core modules can just be git submodules, as this would make a good example for future module maintainers
a main manifest for hyde can facilitate all of this

additionally if the submodules were generated into the main hyde manifest you could also have sharable configurations for users, all under the hyde ecosystem

eg module something like cool-hyde-dots/waybar/manifest.yaml

name: waybar
version: "1.0.0"
description: "Waybar configuration for Hyprland"
dependencies:
  - waybar
  - ttf-font-awesome
stow_target: "$HOME"
paths:
  - .config/waybar

[kRHYME7]

Will definitely Re-try this approach. It's been a year since I first attempted this. In the past it just breaks hyprdots as hyprdots are using symlinks of a symlink way back then. Definitely a skill issue or the structure that time is not for stow.

[kRHYME7]

Is it capable of checking dependency versions each?

[richen604]

If you want to bake this into how Hyde cli does backup restore that will be trickier. stow would make it more complicated

the manifests would entirely be built custom for hyde. scripts for dep installing, installing modules, etc would all need to be made

versioning would be awesome. can you pull specific versions from aur and just run pacman on them?

[kRHYME7]

versions from aur and just run pacman on them

there's a downgrade option. But what I want is to have the dotfiles a minimum/max version table to look up to.

eg. waybar requires at least 0.3.0. So it would prompt to not continue installing as waybar might not be updated or might be in ubuntu.

and also it won't be in HyDE-CLI. I don't want to break hyprdots.

[richen604]

using downgrade would be less ideal if it opens a menu each time, i could imagine that for 8 hyde modules being a press enter simulator

best bet is a validator hyde side on post install for lowest possible version, aur will always handle getting the latest.

[richen604]

max version management seems next to impossible.

could manually fetch and git checkout then makepkg -si with bash? you can prevent updates in pacman config as well. i really dont like that as an idea

[kRHYME7]

yeah, the downgrade reply is for things the user might do. I'm talking about the dotfiles min/max version validation. HyDE can do it. BTW how does stow handle dependency?

if
dependency:
waybar # >= 0.4.0
pyamdgpu # >= version

maybe 🤔 it's possible to parse it first. this way the abstraction part will only be the comments. But that's fragile

Or we can have a bunch of manifest files and we can have a global configuration(hyde specific) file that list the manifest files + dependencies with min version declared. This way we don't make changes to stow no additional checks will be done with stow.

I'm not yet convinced with stow though but yeah saving some time writing my own boilerplate is convenient.Maybe I'm just too confused with symlinks back then lol, now hyde structure is not relying on symlinks except for the wallpaper states (wall.set .blur .sqr )

[richen604]

oh stow does not do package management, only symlinks
most likely would make more sense doing our own symlink management like other dotfiles

[kRHYME7]

that configuration will look like

dots=[
waybar
dunst
kitty

[waybar]

stow-manifest= can be path to manifest

[waybar.dependecy]
pacman= []
dnf = []
yay/paru=[]

....

[richen604]

having both git url and path resolve the manifests would be good too for pulling modules and developing them

[kRHYME7]

most likely would make more sense doing our own symlink management like other dotfiles

I see, we can stick to the old

populate
sync
override

convention we have?

for hyprdots it is

Y|N
N|Y
Y|Y

basically declaring what flags do to files.

[richen604]

so we would need scripts/functions for

• pkg & deps install
• path / link resolve
• dot symlinking (overwrite sync preserve)

flow?
is it main.toml -> modules -> hyde

preserve/overwrite/sync could break modules. but they should have a confirmation / backup system. im not sure it will be intuitive which modules the dots come from in which files

modules need scripts/commands for start boot and "wallbash" so that should be a key/value as well

[kRHYME7]

what you're describing above is almost the same as install.sh workflow but with a friendly interface.

basically modules of dotfiles, I'll call it dots, will be a repo/directory. the toml file will describe it.
after reading the meta data

it should be ready for the flow you mentioned above

1. install the dependencies of the declared dots
2. check if dependencies are installed per dots
3. proceeds to do the populate,sync, overwrite (symlinks if ever stow is convenient)

In the user's end they'll have an interface where they can pick which dots to install. That's basically it.

Important rules:

• When a file is moved/touch it should be backed up beforehand.
• Additional handlers for pre and post installs can be easily added.

Actually I already got the parser part using python (I don't want extra deps). Should I push it publicly, even though it's a WIP.

[kRHYME7]

https://github.com/HyDE-Project/HyDE/blob/master/hyde.toml

dots = ["hyde"]
default_action = "preserve"
user_home = "${HOME}"
package_manager = ["pacman", "yay", "flatpak"]          # "auto" | "pacman" | "dnf"
repository = "https://github.com/HyDE-Project/HyDE.git" # Only supports single repo
start_command = ["echo 'Starting Deez-Dots for HydE'"]
end_command = ["echo 'Command ends'"]

I accidentally pushed the config file a month ago, this is the config that will hold every information of the dot files.
The "users" will only interact with the global part (top of the file) or from a separate interface eg, from file to TUI/GUI

[Olaipai]

Hey,

How about Chezmoi as a manager for the dots and Watchman for possible automation when critical files change?
It supports multi-layer symlinks, and it does not exclusively use them like stow, git integration and version control and can also manage dependencies (I have not tried this myself)
It also creates said dots as a file in its directory and should therefore be quite easy to manage backups for re-installs etc.
It also supports external sources, scripts, m-2-m,

I am not very experienced with chezmoi (or git), but I do use it to manage my dots for my laptop and desktop.
I think Chezmoi might be the solution or a good solution to this. What do you think?

Or I might be completely out of my element and have no clue what I am talking about.