nix

nix copied to clipboard

The uninstall process on macOS is rather complicated since we're now using a separate volume. The install process will print some instructions:

        echo "  1. Remove the entry from fstab using 'sudo vifs'"
        echo "  2. Destroy the data volume using 'diskutil apfs deleteVolume'"
        echo "  3. Remove the 'nix' line from /etc/synthetic.conf or the file"

(note that this will change slightly with #4181)

But expecting end users to understand what they're doing here is not all that great.

We should really consider just writing a file to disk, somewhere in /nix, that when run will do the uninstall. We only need this for macOS users, though we could consider just supporting all installations this way for convenience (especially since this would let us prompt the user about removing /etc/nix). This would also future-proof uninstall instructions in case we need to make changes in the future, as it would uninstall based on how the user installed their current setup, as opposed to instructions on the website which would list whatever the current install process is. For example, the uninstall script would skip any step that the installer skipped such as setting up the Nix volume if the user already did so, though it should of course print a message about any skipped steps so the user can do that themself.

It occurs to me the multi-user installation adds a bunch of build users, so even ignoring the volume stuff, an uninstall script would be great for cleaning that up, as well as cleaning up changes to /etc/bashrc and /etc/zshrc.

I've been thinking about this a little myself given what I'm chewing on at the moment. I'm of a few minds...

1. If we accumulated an uninstall script as we went, we could tailor it pretty closely to the user's install and wouldn't have to worry about the uninstall script "forgetting" how to handle some old practice that was common when the user installed.

2. But I'm bearish on people noticing/remembering that the script is there for long after they install. We had someone throw a big angry hissyfit about leftover Nix crud on macOS after they followed one of the beta Catalina scripts. Their message berating us for not having a way to uninstall literally included a paste of the instructions you included above, but they hadn't bothered reading the output closely enough to notice.

3. If they follow rm -rf /nix instructions from somewhere first, they'll lose the install script.

I'm not quite sure how to square those, but I have 2 main thoughts:

1. Put it in the install script, as an --uninstall flag?
2. Publish an uninstall script at nixos.org/nix/uninstall

In either case, I think there's an argument for both the script retaining the knowledge about how to test for and remove everything (even obsolete stuff...), and for the uninstaller just knowing to look for that local file (the uninstall script written at install time).

As I work through some of the consistency scenarios you brought up on the installer PR, I've been leaning towards putting it all in the installer (not that I see it as a hill to die on) because the logic for spotting inconsistent state, curing inconsistent state, and uninstalling are all pretty closely related. I should have something to show for this soon.

Another option: Add a command nix uninstall-nix. That way you don't need to dig up an (un)install script.

A discoverable uninstall subcommand seems like good (probably the best?) UX for a straight uninstall to me.

I guess the obvious question is if/how often people looking for an uninstaller have an install/store/config broken in some way that would keep them from finding or running the command?

Over time, I suspect the tricky part will be dealing with version difference/drift. It's probably okay to just accumulate rules/conditions for a while, but I can also imagine that breaking down at some point.

I've been wondering if the store should keep some metadata (or maybe a structured log?) that describes how it came to be? I haven't tried to think a complete thought here, but I imagine it being easier to drop obsolete practices from the main code paths if the relevant tools could use information about which installer created the store (and how, and if/when/how any other installers or tools like nix doctor modified it) to find and run any idiomatic steps.

I marked this as stale due to inactivity. → More info

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/anyone-up-for-picking-at-some-nix-onboarding-improvements/13152/6

I marked this as stale due to inactivity. → More info

I'm just coming in, so please forgive but as a "newbie" I wish to gosh I had read the problems associated with nix prior to install... now it looks as if I'm facing a complete wipe of my system in order to remove a single remaining folder that I am refused permission to delete. It's an incredible bother to say the least! I have my Mac long and arduously configured for 3D modeling after about 12 months and wanted to learn some programming to add to my forte... lesson learned I will NEVER install nix again outside of a docker container! Meanwhile if there is any way to change the read-only file system of the nix folder it would be greatly appreciated as I really don't want to go through all the hassle of wiping my drive for a fresh MacOS install absent of all of my apps and files

now it looks as if I'm facing a complete wipe of my system in order to remove a single remaining folder that I am refused permission to delete.

@artcore-c You are definitely not facing that. Follow the uninstall directions in https://github.com/NixOS/nix/pull/6144/files.

Meanwhile if there is any way to change the read-only file system of the nix folder

It's not Nix's read-only filesystem. It's macOS's. https://support.apple.com/en-us/HT210650

the manual uninstall steps are now documented here: https://github.com/NixOS/nix/blob/master/doc/manual/src/installation/installing-binary.md#uninstalling