feat: modular installer architecture#63
Conversation
|
Yeah man, wanted to do this for a while. Ima merge this real quick. |
There was a problem hiding this comment.
Pull request overview
Refactors the installer into a modular lib/ architecture and turns install.sh into a small entrypoint that initializes state, runs the TUI, and executes the install pipeline via module functions.
Changes:
- Split prior monolithic installer logic into dedicated modules (
lib/*) for TUI, detection, packages, dotfiles, services, theming, settings, and telemetry. - Replaced the previous inlined flow with a
main()pipeline that calls clear, single-purpose functions in order. - Centralized constants (version, URLs, package lists) into
lib/constants.sh.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
| install.sh | New entrypoint that sources modules, initializes state, runs TUI, and executes install pipeline. |
| lib/constants.sh | Centralizes versioning, URLs, paths, colors, and base package list. |
| lib/detect.sh | OS/hardware/user-dir/DM detection helpers. |
| lib/tui.sh | fzf-based interactive menus for packages, drivers, keyboard, weather, telemetry, and options. |
| lib/packages.sh | Dependency bootstrap, conflict resolution, package install loop, NVIDIA initramfs handling. |
| lib/dotfiles.sh | Repo setup/pull/clone logic, wallpaper fetching, dotfile copy/update, weather env persistence. |
| lib/settings.sh | Syncs installer-owned settings into settings.json and merges keybinds/startups. |
| lib/services.sh | Display manager + SDDM theme setup, audio, easyeffects, network, zsh, version state saving. |
| lib/theming.sh | Fonts install, system adaptations, env injection, gtk/qt setup, completion output. |
| lib/telemetry.sh | Telemetry ID generation and event POSTing. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| echo -e "anonymous hardware statistics when you start the installation.\n" | ||
| echo -e "${BOLD}What is sent if enabled:${RESET}" | ||
| echo -e " - Script Version, OS Name, Kernel, RAM, DE, CPU, GPU\n" |
| readonly property color green: "#a6e3a1" | ||
| } | ||
| EOF | ||
| sudo chown "$USER:$USER" /usr/share/sddm/themes/matugen-minimal/Colors.qml |
|
|
||
| #!/usr/bin/env bash | ||
|
|
| echo " -> [--local] Используется локальная версия: $REPO_DIR, git pull пропущен" | ||
| else | ||
| echo -e "${C_RED}[--local] .git не найден рядом со скриптом ($SCRIPT_OWN_DIR).${RESET}" |
| setup_display_manager | ||
| setup_repo |
| HAS_NVIDIA_PROPRIETARY=false | ||
| LAST_COMMIT="" | ||
| KEEP_OLD_ENV=true | ||
| ENABLE_TELEMETRY=false |
| case "$mode" in | ||
| init) | ||
| payload=$(cat <<EOF | ||
| { | ||
| "type": "init", | ||
| "version": "${DOTS_VERSION}", | ||
| "id": "${TELEMETRY_ID}", | ||
| "os": "${OS_NAME//\"/\\\"}" | ||
| } | ||
| EOF | ||
| ) | ||
| ;; | ||
| full) | ||
| payload=$(cat <<EOF | ||
| { | ||
| "type": "full", | ||
| "version": "${DOTS_VERSION}", | ||
| "id": "${TELEMETRY_ID}", | ||
| "os": "${OS_NAME//\"/\\\"}" | ||
| } | ||
| EOF | ||
| ) | ||
| ;; |
|
Okay, so 1. Why did you change the telemetry to off by default? You said no behavior was changed. 2. The setup display manager has to come after setting up the repo since, well, if the user setups sddm, the script wouldn't have the needed files for it. 3. Why are there russian logs? where does that even come from? seems like you got confused. @Ast1gmatism fix those, and I can merge. |
|
Its there going to be any response on this? Cause if not, ill do it myself |
|
sorry about the telemetry, will fix that and other things now |
|
Oh yeah, and the whole "apply once" pr that you made is probably good, but I wouldn't wanna merge it. Are you sure there is nothing in this PR that relates to that? |
|
hey @Ast1gmatism so I am grateful for your PR and i think this is good, but the issue is that I have just reviewed another PR that adds some GUI functionality and it is good, but it relies on the old install.sh. Resolving conflicts would be too long and unproductive, so I think what I am going to do is to merge the PR #57 and then if you can resolve all the branch conflicts i could merge this too. |
|
ok, no problem, thanks for the review. will wait to #57 and fix things up after that |
|
@ilyamiro saw your reply on that PR, what did you end up deciding to do? |
|
Hey so the problem with the whole setup was that using sed or grep or whatever for inline changing of the config is very fragile. I have decided to move to just generating .conf files from templates to eliminate any problems. That virtually makes all of the "adaptability" phase in the installer useless. Im not sure where im gonna go with splitting the files but i will let you know. Okay? |
|
thinking about it - would it be easier to merge this modular split now and then rework the adaptability phase on top of it? the new structure keeps things isolated, so swapping the sed stuff for templates wouldn't touch the rest. but I'm fine waiting too, just an idea. let me know |
|
I just wanna keep everything sorted in my mind before i merge this and i agree that this is good but give me a day or two and i will come back to you. |
99ad5f2 to
5a42883
Compare
|
@ilyamiro just rebased on latest upstream and resolved all conflicts, ready for review when you have time |
|
@Ast1gmatism new install.sh needs to have DOTS version, the way my updates work is that the server checks this version file. Could you add that? |
|
also, can you make sure there are not trailing whitespaces in any of the files? |
|
sure |
|
dont merge this branch yet, just found a bug in settings apply logic |
|
Wait wait, is this the same logic I have in my original install.sh, or are you fixing my logic? |
|
done, now everything should work |
|
about backup, i tried to fix it because splitting into full and partial install broke the local paths. i fixed that part, but the underlying logic stayed the same, and the new installer now behaves like the original |
|
@ilyamiro what do you think? |
cbab0e0 to
03cc319
Compare
splits that gigantic install.sh into separate files under lib/ – one for packages, one for themes, one for the TUI, and so on. the main script now just calls a few clear functions: detect the OS, ask the user what they want, install packages, copy dotfiles, apply settings, and that's it. no behavior is changed – all old features (keyboard setup, driver detection, etc.) work exactly like before
the original script was very hard to do something in it without breaking something. now each module is self-contained, and the main() function shows the whole installation pipeline