Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[RFC 0127] Nixpkgs "problem" infrastructure #127
[RFC 0127] Nixpkgs "problem" infrastructure #127
Changes from 2 commits
60cb23d
ee72999
c109c31
ff2e2d4
f83067a
2daf978
2b63424
e5c0e13
3212d31
ecdbe2c
c907adb
d232a2d
ff6e33d
6ffce6d
24a8985
1b1424e
1e6725e
81564e6
c5c64ec
2a78241
4f311de
b253df1
7939f49
33ec9a6
83319ec
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Who needs it and why? What use case is not served by
lib.warn
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lib.warn
can only be used in a limited fashion due to ofborg's clean eval requirement (no warning messages may be printed when doing the normal eval check iirc). We could of course lift this requirement as an alternative.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Real) warnings are an important feature, and ofborg must not stop us from using it.
We can make ofborg pass a Nixpkgs
config
flag to suppress expected warnings. This could be implemented as a list (or nested attrset) of attribute paths that have known issues, that cause ofborg to skip those attributes in its clean eval.aliases.nix
can already serve as such a list, combined with a separate list for other issues such as described in this RFC.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently we have the informal "mark it as broken, wait, add alias" system. How is this better for that?
rg 'broken\s=true'
is easy. Would that be an automatically-generated warning? More future potential.. (more room for metadata → r-ryantm style bot that removes packages that have had certain issues added to them → it can also make those issues)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That informal system is so informal that I've never heard of it or encountered it in practice, at least not for the use case of removing outdated packages that still technically work otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to look for references when I posted that but timed out after a minute to continue with the review. Left it here as a future TODO, something for the future work subheading?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add as sub-point: out of band warnings would be impure if they stopped evaluation like they currently do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I imagine such a tool not blocking evaluation at all, but providing the metadata, comparing it to local policy, annotating the drvs produced with said metadata, and (when used interactively) providing a "continue anyway" knob if anything happens that's not already permitted by local policy.
I don't count that as an impurity, since I don't want it to be able to modify the evaluation results at all -- only observe evaluation and decide what to do afterwards (which also allows getting all the warnings at once, and displaying all those that local policy considers as "blocking" at once).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Flag"?
I don't like that "issue" collides with nixpkgs's github-based issue tracking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking outside the box here. Perhaps these terms might be useful?
gate, inhibitor, flaw, condition, concern
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about calling the nixpkgs config option simply by what it does, maybe something like
checkMetaHandler
? Because I think this is the only user-facing place where this entire "feature" needs a name. (For the package side, I still think "issues" is the least bad name so far)