Add omakub uninstall
dhh opened this issue · comments
The default should be a no-configuration setup that includes a broad selection of what most people need.
But you should certainly be able to take things out of the box that you don't want.
Let's add a serious of uninstall scripts, so you can run "omakub uninstall" and pick any of the pieces you'd like to see removed.
@dhh how can I completely remove the whole omakub?
Right now, there's no automated way of doing that. Would be happy to see a script added that does that, though.
Going to take a look at this. I agree with @Areeba-Khaliq there defiantly is some potential value in being able to fully unistall if desired with minimal headache
another aspect of this would be to have an interactive list of "apps" where you could uncheck the boxes to avoid install.
Personal opinion and there are many ways to approach this! I think the install should have everything to avoid complicating things and taking away from the "magic" of the one command and done
Then after the fact if you need to/want you can pick apart the stuff you don't need?
I would generally agree if the one script wasn't that long. On my FW13 it took roughly about 10 min to run and 3 min of it was ruby dependencies I don't need. Now imagine we have several other languages like PHP discussed here :#73 this would hinder performance.
For other apps I think it's fine (like spotify, signal, etc..) to uninstall them afterwards. But for the dev environment, you probably could have a "branch" by setup, where you could use
install --full
install --with-ruby
install --with-php
install --with-node
install --with-ruby --with-node
This could be listed on the website and thus still making a one-liner to copy/paster, but having bundles of dev envs to choose from.
I think a good first iteration will be to just allow people to uninstall apps after installation (apt remove / purge + remove manually some files if needed). Each app could have an install & uninstall script.
But I agree with @florentdestremau that if Omakub vision is to add default support for other languages (#73) and give more options, it'd be great to have an interactive list (with gum?) to select from on install. If not, the default installation might be too bloated (not just the installing time, but having a system with a bunch of things that you don't need)
For handling uninstallation we can utilize the existing scripts with an extra arg -u/--uninstall/u/uninstall
to the source script commands
Something like:
# Run uninstallers
for script in ~/.local/share/omakub/install/*.sh; do source $script -u; done
Then we can update scripts in the install directory with a check for args and reverse the operations done during install.
case "$1" in
"--uninstall" | "-u" | "uninstall" | "u")
# Uninstall commands
;;
esac
# rest of install script
Using case option here, will help with easily expanding the scripts with more options in future and also simplifies argument checks
This will help with code organization, as install/uninstall scripts will be in the same file.
Another worthwhile change would be to have the install
dir renamed to setup
or something more suited as it will contain scripts that both install and uninstall
@TomJCoutts this may be helpful 😄
@2KAbhishek That seems like an elegant approach! It would avoid having two scripts to maintain which is a win 😅
Not sure having everything in one script helps. There's no shared code. So making one file do two things, when there's nothing really shared, doesn't strike me as likely to be better. Now you need to check parameters and more. To me, adding uninstall/*.sh seems simpler.
I agree that having a separate uninstall directory might be simpler, but the reason I wanted to propose a shared file was so that we can see both the install and uninstall commands at the same time.
This may come in handy when debugging and later with maintaining.
For example:
For a particular file, let's say bash, I know that the config file is named ~/.bashrc.bak
So while uninstalling I know which path and filename to use. We can even create shared variables like:
CONFIG_PATH
and BACKUP_FILE
etc. to aid in this.
Something I would again say will help with maintaining, but totally understand if the group wants to go the other direction :)
Appreciate that, but don't think it outweighs the simplicity of having 1 script do 1 thing.
Added this.