Anyone up for picking at some Nix ~onboarding improvements?

2 improvements this Spring laid a foundation for big wins on ongoing pain points:

  1. CI (GitHub Actions) for nixos/nix now generates full installers and runs installer tests for Ubuntu + macOS. You can trivially set this up to run on your fork.

    (If the cumbersome process of manually testing changes taught you to avoid touching the installer, I suggest giving it a fresh look. It’s hard to overstate how much easier it is!)

  2. In the course of #4289 darwin: encrypt nix volume if filevault is enabled, I developed some new patterns for ~curing inconsistent artifacts on macOS that can be re-used elsewhere.

I’ll save detail for a follow-up, but generally these light the path to:

  • installer support for --uninstall and reinstalling over existing installs
  • expanding test coverage of different install scenarios

I need to focus on other projects for a while and won’t have time for these UX/DX investments for at least a few months, but I’m happy to help others get up to speed and provide feedback.

6 Likes

Can the full installers from (1) be fed to install-nix-action the way numtide’s nix-unstable-installer is currently? (I ask because unstable has been rocky lately and constant new releases to update to would be helpful.)

I haven’t used the numtide installer, but AFAIK the answer is yes (this is how the tests work). The .yml may be a good resource for more detail:

1 Like

Following up on what I think the projects/work here are. There are at least two (and maybe more) parts that can be separated if there are enough hands.

This is probably a single project.

  • I did a proof-of-concept towards this back in late October. It’d need some defrosting, but it may help get started. Here’s the commit where I removed that experiment from my WIP: drop uninstaller code for now · abathur/nix@630a91c · GitHub

  • It’ll be easier with access to Linux and macOS, but it may not be essential.

  • I think the bulk of the work should be semi-straightforwardly applying patterns from #4289 to individual artifacts and state changed by the installer.

    Shooting from the hip, but AFAIR the patterns address:

    • prompting the user (optionally with sudo/password for more-serious changes) for adding/removing something
    • showing them the change as needed
    • queuing reminders (next steps, notes, etc.) for presentation afterwards
    • granular add/remove uses the same work to support both --uninstall and reinstall (remove, add)
  • The “harder” problem (and the part that might be splittable?) will be figuring out what to do with/about the single-user install mode (and getting buy-in).

    • I think this can wait until the features work in the multi-user installer and it’s possible to demo the experience.
    • IIRC the outer installer targets posix sh, while the multi-user installer specifies bash.

This should be easier to split up into more work.

  • There are many distinct cases wrt shells people use and what profile/rc files they have present.
    • Ideally, the test should cover starting a new shell (without inheriting env) to verify that the shell startup is working correctly.
    • This process may also help find conditions that the installer can be testing for and either curing or alerting the user about.
    • Populating distinct test-cases should be a fairly shovel-ready contribution to clarifying what does/doesn’t work and avoiding regressions. Issues filed against Nix may be a good resource for detail.
  • Install tests currently use install-nix-action, which IIRC limits it to multi-user installs. In order to add single-user test cases, we may need some support in install-nix-action, or a replacement mechanism dedicated to testing?
  • The --uninstall/reinstall work above should be able to build on top of the distinct shell/setup cases. There may be some prep work WRT to being able to validate the result of removal/reinstall.
1 Like

I took a little time to find some summary of the proof-of-concept I mentioned before. I think the removal commit may be the most-cohesive single reference: drop uninstaller code for now · abathur/nix@630a91c · GitHub

(apologies if you follow many issues below and got thoroughly spammed by this)

To help cross-link and in case I get hit by the proverbial bus, here are some notes I compiled during #4289 of issues open at that time which I believe the project(s) described here can close: