rfcs
rfcs copied to clipboard
NixOS
[RFC 0169] Feature parameter names
RFC to establish rules on how enable/with/support/use flags should be named. Essentially, an attempt to bring order and uniformity of Gentoo USE flags into Nixpkgs.
Pre-RFC discussion on the discourse Rendered RFC
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/pre-rfc-standardization-of-feature-parameters/38104/74
As proof-of-concept, implemented renaming logic on the makeOverrideable level. That means that individual packages
do not need to carry deprecation notices (something that @Atemu called "ffmeg" test).
Side effect of this approach is that it actually provides list of all known feature parameters. I'll probably move this approach as proposed, and current one as alternative solution.
https://github.com/NixOS/nixpkgs/pull/284107
@infinisil Can I have your input? I think at 2024-01-09 nixpkgs architecture meeting you expressed interest in shepherding this one.
@jtojnar @ghost @mohe2015
Inviting reviewers of #234463 into the RFC discussion.
Feedback is welcome. Finding more people to get RFC
received ample discussion and enough of the tradeoffs have been discussed.
is also welcome. I think on my side, I did proof-of-concept both on how to lint new packages and how to do renaming in existing. Anything I miss?
My current opinion is: motivation mismatches the measures proposed; switching the naming word-handling convention is costly and the changes elsewhere have deprived it of the main benefit in terms of linting; the linting being mandated but not the trigger condition for the more onerous requirements timing is bad.
Unification of option naming where only the names already used in practice are eligible — via should-merge stipulation for zero-rebuild PRs in that direction — would not bring practical benefits either but at least would be mostly harmless.
I won't actively support even the latter reasonable version of unification, so I guess I am too biased to be a shepherd. I hope though, that I manage to keep the local feedback useful either to reject the substance and not silly technicalities, or to implement it with less unnecessary cost, useful or not. (Costs inherent to the claimed benefits are a trade-off question, we will never get agreement there, only a truce)
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/extra-packages/39867/6
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-03-05/40851/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-03-19/41829/1
This RFC has not acquired enough shepherds. This typically shows lack of interest from the community. In order to progress a full shepherd team is required. Consider trying to raise interest by posting in Discourse, talking in Matrix or reaching out to people that you know.
If not enough shepherds can be found in the next month we will close this RFC until we can find enough interested participants. The PR can be reopened at any time if more shepherd nominations are made.
See more info on the Nix RFC process here
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-04-02/42643/1
@AndersonTorres There are no shepherds right now but three are required. (While I would be a good candidate, I'm a bit overbooked right now, so I'd prefer to only give occasional feedback.)
I am interested in implementing this. So I wanna be a shepherd.
However I am on vacation now, I will return after 15 days.
@wolfgangwalther Thank you for thorough revision of the text.
I find your reasoning about consolidating knowledge of package availability quite compelling. Having with_ flags naming strictly derived from package name sounds good, but there might be some corner cases where MUST will paint us into the corner.
@7c6f434c @Atemu Thoughts?
but there might be some corner cases where MUST will paint us into the corner.
Two thoughts on this:
- Making this a MUST is much more likely to make us aware of those corner-cases, because somebody would need to raise the issue if they come across that case. A SHOULD would possibly lead to silent divergence of
with_flags and attributes. - Maybe we can find a way to express that those corner cases must then modeled via
enable_flags and notwith_flags, to keep the strict 1:1 mapping forwith_flags and attributes?
My current thought is that after some independent evolution the proposed policies have lost connection to the motivation, and the current proposal involves currently unjustified massive changes, like switching from camel to snake case. Which is bad.
Awareness of corner cases is only worth anything if something reasonable is done with them; the current intermediate state of the RFC already doesn't pass this threshold.
My base estimation of the decision making processes in Nixpkgs is that throwing MUST requirements into an RFC to force the corner cases to the light will be a pure negative if done naively. Maybe a clear procedure for creating generic rules for the corner cases which is a MUST for any exceptions could work, but that's not what is discussed currently.
the current proposal involves currently unjustified massive changes, like switching from camel to snake case.
The justification to use snake case for those feature parameter names is the ability to have a 1:1 mapping for attribute names and with_ parameter names. This is not possible with camel case, because attributes don't start with a capital letter.
My base estimation of the decision making processes in Nixpkgs is that throwing MUST requirements into an RFC to force the corner cases to the light will be a pure negative if done naively.
This is not the intent/motivation of the MUST requirement, just an observation of a potential side-effect. I proposed the MUST requirement for with_ parameters to avoid any divergence between attribute names and parameters names and thus enable automation on them.
The justification to use snake case for those feature parameter names is the ability to have a 1:1 mapping for attribute names and with_ parameter names.
However, the currently proposed rules for what is the real dependency parameter to mention are complicated enough that no automation is plausible, so we can just write should-accept for unifying renamings and keep camel case — given that for most cases it is clear what is the proper camel case.
@wolfgangwalther shepherding is probably the best way you can help this RFC get forwards, so we'd like to nominate you as a shepherd -- let us know if you're alright with that :)
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-04-16/43512/1
Overall, I do not agree with @wolfgangwalther's proposal to add global parameter mechanism to this RFC or tie parameter naming to a global goal.
The possibility of making such Gentoo-like USE-flags a reality is one fo the goals of this RFC as I understand it. Actually doing that should be explicitly excluded from this RFC though IMO.
As I understand it, limiting it in this regard was intentional and I'd agree with that. A USE-flag like mechanism entails a lot of other design decisions and problems to solve than setting a standard on the naming of parameter names. This standardisation can be useful without the global mechanism and it'd be best to keep the RFC for it minimal.
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-05-14/45414/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-05-28/46113/1
RFCSC:
@wolfgangwalther: Asking again, would you be willing to shepherd this RFC? Furthermore, we're also nominating @Atemu as a shepherd, since you recently reviewed it, sound good?
@infinisil
Asking again, would you be willing to shepherd this RFC?
Sorry, for not answering so far. I had put this on the backlog, because nobody else was available to shepherd anyway, so it wasn't urgent for me.
tbh, I don't know. This whole proposal is based on two key assumptions:
- We don't have a module system for packages.
- It's not possible to add "nested default arguments" to a function.
Both of those would allow superior solutions to this. But having no solution is clearly inferior.
I only briefly looked at @Atemu's https://github.com/NixOS/nixpkgs/pull/312432 - but this is an approach targeting a more principled solution. If that's feasible at all - we should pursue this instead.
So I would say at this stage we can't reasonably push this RFC forward - to neither direction. Accepting this wouldn't make sense if @Atemu's approach works out well. Rejecting this now, doesn't make sense either, because we just don't have this other proposal anywhere close, yet.
Imho, we should put this RFC on hold for a bit, maybe build a team to evaluate https://github.com/NixOS/nixpkgs/pull/312432 and push this forward, possibly resulting in a different RFC. Once we have a better idea whether that approach can work, then re-consider this RFC here?
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-06-10/46817/1
This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/rfcsc-meeting-2024-06-24/47589/1