Add omakub uninstall

[David Heinemeier Hansson]

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.

[Areeba Khaliq]

@dhh how can I completely remove the whole omakub?

[David Heinemeier Hansson]

Right now, there's no automated way of doing that. Would be happy to see a script added that does that, though.

[Tom Coutts]

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

[Florent Destremau]

another aspect of this would be to have an interactive list of "apps" where you could uncheck the boxes to avoid install.

[Tom Coutts]

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?

[Florent Destremau]

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.

[Carlos Sánchez]

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)

[Abhishek Keshri]

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 😄

[Tom Coutts]

@2KAbhishek That seems like an elegant approach! It would avoid having two scripts to maintain which is a win 😅

[David Heinemeier Hansson]

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.

[Abhishek Keshri]

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 :)

[David Heinemeier Hansson]

Appreciate that, but don't think it outweighs the simplicity of having 1 script do 1 thing.

[David Heinemeier Hansson]

Added this.