mobile-nixos
mobile-nixos copied to clipboard
Added flake support and helper
This pull request integrates Nix Flakes into this repository while maintaining backwards compatibility. I also added some documentation showing how users can utilise flakes.
Changes done:
- nix-shell is now defined inside the Nix Flake, providing a shell.nix as compatibility shim
- device configurations are exported as
nixosModulesallowing users to configure their mobile-nixos - the overlays are now properly exported under
overlays(andlegacyPackages) so you can easily use this repositories' packages - provided a helper function to easily define a flake which creates a mobile-nixos system
Hi, thanks for the contribution!
While I'm not a Flakes hater, I'm not a Flakes believer either. Though I will say that most of this comes from me willingly not looking into that. I don't have the mental bandwidth to learn and correctly understand Flakes while working on all my side-projects.
Some technical questions that you might be able to answer/solve. Sorry if it seems like a lot to dump on you!
Is the bare nix build with a Flake-enabled Nix different when flake.nix exists? How does it differ?
[There are additional in-line comments to look at...]
So yeah, I'll have trouble dissociating my opinions about that while considering adding Flakes support.
Additionally, until it is enabled by default as part of a stable Nix release I'm not comfortable with adding Flake support.
Hi @samueldr , I'm glad you reviewed my PR so thoroughly. While it took me a while to answer all your questions it also helped me to better understand some aspects. If you have further questions, I'll happily answer them for you.
nix build is supposed to be a replacement for nix-build, it also has a different syntax. Note that nix-build (with the dash) does not change behaviour when flakes are enabled, so the repository can still be built normally with nix-build even with flakes enabled. nix build on the other hand is only available when flakes are activated. So it's cli follows a more "flakes first" approach, it is always of the form nix build <flake-ref>#<flake-attrib>. However, you can still build "normal derivations" by using the -f flag. These two commands are equivalent:
(old nix-build)
nix-build --argstr device uefi-x86_64 -A build.default
(new nix build)
nix build -f default.nix --argstr device uefi-x86_64 build.default
Regarding the documentation I added a second paragraph explaining the need for the mobileFlake helper. However, I feel that it may be a bit "too in-depth" for a getting-started doc. Ultimately we may need to decide which knowledge about flakes we require from the reader. A flake tutorial would be definitely out-of-scope but my previous doc was a bit hard to understand.
I understand that you are not willing to add flakes support as long as they are experimental but maybe you can consider some points:
- It is an addition to repository. I tried hard to not change any existing behaviour. So for new mobile-nixos users they can still use the existing documentation while more experienced flake users can probably figure it out by themselves how to utilise them.
- The flake interface is probably not going to change anymore even though it is marked as unstable. I made this PR while participating in the Summer of Nix and there is already a lot of effort (and money) spent to establish new flakes. It is highly unlikely someone will introduce a breaking change.
Have a nice day, ostylk
(Sorry, this comment is extremely tangential...)
Right, the fact that unqualified nix-build and nix build will differ is a big issue here IMO (and not really of your doing).
nix buildon the other hand is only available when flakes are activated.
This is not right.
~/.../mobile-nixos/mobile-nixos $ nix --version
nix (Nix) 2.3.15
~/.../mobile-nixos/mobile-nixos $ nix build
error: Please provide a device name using e.g. `--argstr device $DEVICE`.
The current stable version of Nix allows use of nix build.
But you're right with nixUnstable! nix build was disabled without enabling a specific flag separate from Flakes support. Additionally its UX has been changed in 2.4; I'm not sure about that UX decision about unqualified nix build using flake.nix only.
# Without a `flake.nix` file present
[nix-shell:~/.../mobile-nixos/mobile-nixos]$ nix --experimental-features "nix-command" build
error: path '/Users/samuel/Projects/mobile-nixos/mobile-nixos' is not a flake (because it doesn't contain a 'flake.nix' file)
# with a flake.nix file present
[nix-shell:~/.../mobile-nixos/mobile-nixos]$ nix --experimental-features "nix-command" build
error: experimental Nix feature 'flakes' is disabled; use '--experimental-features flakes' to override
[nix-shell:~/.../mobile-nixos/mobile-nixos]$ nix --experimental-features "nix-command" build -f default.nix
error: Please provide a device name using e.g. `--argstr device $DEVICE`.
I care deeply about the "default" "unqualified" nix-build or nix build invocation in my Nix-built projects, and frankly, that new nix build command will be confusing.
At the very least with current nixUnstable the unqualified nix build tries to act the same whether Flakes support is enabled or not. Though the unqualified nix build differs from nix-build, and from the (unstable interface from) nix build in 2.3.
Though this still means that the end-user docs has to be careful about pointing out nix build -f [...] sooner rather than later, as otherwise flake.nix might be inadvertently used by someone that's used to using nix build, or that didn't exactly notice nix-build vs. nix build. I don't really know how this breaking change in UX between the two CLIs can be reconciled, if it can even be.
Sorry, this is not something I expect you to solve. Though if you have thoughts please share
#406 allows for the nix build command to be as easy as you'd like, with this commit https://github.com/ngi-nix/mobile-nixos/commit/5ae97728706165ae49e82937dc16ebc1e6fe9f71 (which I'll cherry-pick into this PR, as soon as #406 is merged) I added a defaultPackage attribute to the flake. So when the user executes nix build it automatically builds the default output from config.mobile.outputs.default. Works like a charm.
I'll wait for #405 and #406 to be merged.
I rebased this PR and consider it ready for merging:
pkgs.nixnow retrieves the current nixpkgs revision fromflake.lock.flake.nixnow importsshell.nixinto its devShell attribute (with proper nixpkgs version)- When using the
mobileFlakehelper, it automatically maps against the user-facing outputs mobile-nixos provides. It even sets thedefaultPackageso a normalnix buildwill build the correct output.
It's there any way I can help move this forward? I'm curios about trying this on my old OnePlus but would love to have the same workflow as on my computers.
I suspect the blocker is still this
Additionally, until it is enabled by default as part of a stable Nix release I'm not comfortable with adding Flake support.
just wanted to share my example-repo that demonstrates how i currently use mobile-nixos in combination with flakes. hope this is helpful for anyone: https://github.com/betaboon/mobile-nixos-flake
Additionally, until it is enabled by default as part of a stable Nix release I'm not comfortable with adding Flake support.
Is this still the stance @samueldr? A year and half have passed, so hopefully I'm not out of line for asking.
a long time has passed since this PR was put up, Flakes have come a long way since then, and are starting to become more widely used. I would really like to see this project get flake support.
There's a recent thread on the NixOS discourse about the experimental state of Nix flakes. There's also a plan to stabilize Nix flakes being worked on in this RFC. Apparently the RFC is close to entering FCP (Final Comment Period). The bottom line is that there is no timeline yet, but it is actively being worked on.
@samueldr Are there any changes we could make to this PR that would make it mergeable before Nix flakes exit the experimental state? I'm thinking about adding a disclaimer in the documentation about the experimental state of Nix flakes, and possibly moving the flake files in a sub-directory instead of the root directory.
let's do this!
:(