* Fetch updates from i.d.s by default
Our goal is to deliver a solid experience with Nix flakes, including an upgrade path that is safe. Occasionally, the upstream Nix project may introduce regressions for the common flake path. This is not desirable for our users, who depend on a consistent and stable flakes experience.
Additionally, the Nix project isn't directly responsible for delivering updates to users as that role is delegated to the Nixpkgs project.
Overall, this means upgrades are not consistently delivered to users.
This update directs future update requests to install.determinate.systems, which we will upgrade as part of our standard release process.
Our standard release process includes proactive testing: validating our installer and Nix's behavior across a wide variety of platforms and scenarios.
After an update passes our proactive validation, we do a phased rollout of reactive monitoring: the update is released to a small percentage of users on GitHub Actions. We monitor the failure rate of the installer and overall workflows to ensure the updated Nix isn't causing widespread failure we weren't able to identify ahead of time.
Only after a release passes both proactive and reactive validation, our macOS .pkg and nix-upgrade paths are bumped to the most recent release. This gives user the confidence they're looking for that the Nix release they're getting is safe.
* Universal -> universal
* clippy: unnecessary guard
* create merge nix config clippy nit, old
* Clean up a clippy nit on an extra clone
* clippy nit legacy wsl detection error
Making everything 0o555 is too much, since many files in the store
are not supposed to be executable. Those should be 0o444. Instead
of splatting 0o555 out, take a more measured approach and remove
the writable flag from the on-disk mode.
* Support remote-building to macOS hosts
Our README has long featured a snippet to add to the zshenv, with a
caevat that it might behave strangely if you're writing a script with an
empty PATH.
It is pretty straightforward to eliminate those caveats while still
providing remote building for Nix to macOS hosts.
Co-authored-by: Ana Hobden <operator@hoverbear.org>
* Add cargo-watch
* clippy: the borrowed expression implements the required traits
* clippy: expression creates a reference which is immediately dereferenced by the compiler
* clippy: redundant closure
* clippy: this if-then-else expression returns a bool literal
* clippy: explicit call to .into_iter() in function argument accepting IntoIterator
* Clippy: an implementation of From is preferred since it gives you Into<_> for free where the reverse isn't true
* Support cargo building on a mac
* Create a nix-hook service on macos to inject the shell at startup
* Introduce nix-installe restore-shell to fix the init scripts, called by the nix-hook plist on every login
* Wait for /nix to be there, and restart the hook until it works
* Back to run-at-load hoping that works
* Revert "Back to run-at-load hoping that works"
This reverts commit cccb8bcd971e296fecc0a2dba4f1101795bcd5ba.
It starts too early, fails, and then aborts. When it fails,
launchd says the service failed to initialize and that the system
is read-only.
* nits
* rename to repair
* Handle --no-modify-profile
* fmt
---------
Co-authored-by: Ana Hobden <operator@hoverbear.org>
* Switch to flakehub
* Diagnostics: support user-defined attribution.
Allows a user to specify an additional value to associate their diagnostics with that value. nix-installer doesn't generate or store these values, and most users have no need for it.
* Respond to feedback
* Make nix.conf changes deterministic
* Add mac fixture
* Warn/error if user settings don't match our needs
* Repair mac fixture
* fmt
* clipster
* Tidy up some feedback
* fmt
* resolve some nits
* Add Upgrading section to README.md
* Change upgrading note README.md
* Change upgrading section at README.md
Remove note.
Add explanation of which version will be installed.
* Use an h3 instead
* A bit less detail...
---------
Co-authored-by: Ana Hobden <operator@hoverbear.org>
