handle permissions issues for --update arg

[NotAShelf]

Tries to open flake.lock with both read and write permissions (which should, in theory, be enough to avoid failures due to flake.lock being owned by root.

If it fails (e.g., due to insufficient permissions or the file not existing), it bails with the error message and a short warning.

[NotAShelf]

Might address #79

[viperML]

I don't know the purpose of this. Nix already complains with flake.lock: Permission denied

[NotAShelf]

to handle the error ourselves :)

[viperML]

another option is wrapping the update command with .wrap_err https://docs.rs/eyre/latest/eyre/trait.WrapErr.html#tymethod.wrap_err

[viperML]

But thinking about it, an error in the update command might be caused by other things, so it sounds reasonable to pre-check for the flake.lock permission error. Although I would add a message saying that nh doesn't support updating flakes owned by root

[NotAShelf]

Error message is a bit better now.

Side note, I was unable to test this because even when my flake.lock is owned by root, it can still update on my system. So, testing on a sane system would be appreciated.

[NotAShelf]

Side note, the file check should probably go into util.rs as a function since it's the exact same in both home-manager and nixos command interfaces, but I don't have the the time to get on that.

[NotAShelf]

Does nh attempt to read flake.lock before the rebuild? Looks like permission denied error is given before we can reach the check.

[viperML]

In home.rs, it is read some lines before to check for the HM output

[NotAShelf]

I'm currently testing with nh os switch - should home.rs still be referenced in this case?

[viperML]

no

[NotAShelf]

Then I have no idea why we are not getting the custom error message.

[viperML]

it's so over

[NotAShelf]

nhover

[viperML]

@NotAShelf should I close this PR?

[NotAShelf]

If you are uninterested in figuring out why the behaviour occurs, feel free.