Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use mobile.outputs rather than system.build #406

Merged
merged 48 commits into from Aug 30, 2021

Conversation

samueldr
Copy link
Member

@samueldr samueldr commented Aug 27, 2021

system.build is, at best, a wart in the current design of the NixOS options. It is an arbitrary attrset full of arbitrary under-defined values. This, in itself, eh, is an implementation detail.

The issue is that Mobile NixOS started with using that catch-all property to transmit internal and user-centric outputs. Now, that is a problem. First, we have to dance around any possible names used by NixOS, as it's just an attrset, without mkForce and similar merge semantics.

The solution here, and probably should be investigated by NixOS to provide better composition semantics, is to provide all outputs as discrete options in the options system. Internal-use ones are marked internal.

Side-note: It has been implemented under the mobile.outputs namespace, but that's not the only possible design. In ██████, a WIP project, any relatively independent options namespace has its own outputs attrset. This is because the intent there is to allow multiple divergent implementations of modules, internal and external, to co-exist gracefully. Though here Mobile NixOS is a monolithic composable layer on top of the ultra-monolithic NixOS, so it's fine this way.

Drawbacks

The main drawback is that I moved things around.

There is a minor drawback in that outputs are now namespaced by system-type, e.g. outputs.android.android-flashable-bootimg rather than build.android-flashable-bootimg. But this is minor since when the evaluation is done imperatively (e.g. nix-build ./default.nix) the system-type's sub-attrset is merged into the outputs attrset. So in the end it's outputs.android-flashable-bootimg.

outputs rather than build?

I find that outputs better describe what it is. A build is really a build artifact, or a build output. While this somewhat breaks backwards compatibility by renaming the attribute, I think it's totally fine to do since this

TODO

  • Comb over documentation for build.* references.

Maybe for now, maybe after?

  • Add exportedOutputs or similar attrset for documentation purposes.
  • Use exportedOutputs in device pages, show a table of possible outputs.

Additionally properly mark `build.rootfs` as deprecated.

But since that output is kind of special, allow a direct reference!
@samueldr samueldr marked this pull request as ready for review August 27, 2021 05:22
@samueldr samueldr added the 4. type: enhancement New feature or request label Aug 27, 2021
@samueldr
Copy link
Member Author

samueldr commented Aug 30, 2021

Hmm... the documentation generation causes an OOM.

This will be fun.

I might undo the documentation change and shift this to later.

@samueldr
Copy link
Member Author

See #409.

@samueldr samueldr merged commit fb361f5 into NixOS:master Aug 30, 2021
@samueldr samueldr deleted the feature/mobile-outputs branch August 30, 2021 23:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
4. type: enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant