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
emacs: teach elisp builders the finalAttrs pattern #330589
emacs: teach elisp builders the finalAttrs pattern #330589
Changes from all commits
3b82c96
675dcef
cdf4aef
84c2e00
37df73d
5248f6f
5805cf2
e64ccec
bdd7734
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.
Almost all other attrs are overridden by user-defined values. Applying that pattern to
postInstall
means changingpostInstall = '' .... '' + postInstall
topostInstall = args.postInstall or '' ... ''
, which means if users definepostInstall
, their package never does native compilation. I think this is very bad. However, inconsistence is also not good. WDYT?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.
Well, well, well...
Searching some packages, I have found that e.g.
copyDesktopItems
injects itself at postInstallHooks.It implies that post installation hooks are "queued" but not destroyed/substituted.
(And it explains why we need to never forget the
runHook pre<phase-name>
...)That being said, curiously the consistency is not in substituting pre/post phases, but in queueing them.
So I vote for
+
instead ofor
.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.
Note that there are two kinds of postInstall hooks, one is defined in nix files with the attr
postInstall
, others are defined as an array calledpostInstallHooks
in setup hooks. For the first kind of hook, it is indeed destroyed/substituted. For the second kind of hook, generally it is queued usingpreInstallHooks+=(...)
. Here, we only talk about the first kind of hook.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.
Another question, which one of the two orders should be used for
+
,postInstall = '' .... '' + postInstall
orpostInstall = postInstall + '' .... ''
?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.
Not something to address here and now:
Do we really need to use
writeText
for the recipe? Couldn't it be done inline in the builder instead, skipping the intermediate derivation?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.
Sounds good. I created #334888 to track this potential improvement.
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.
Almost all other attrs are overridden by user-defined values. Should we apply that pattern to
preUnpack
for consistency, i.e., changingpreUnpack = '' ... '' + preUnpack
topreUnpack = args.preUnpack or '' ... ''
? The same question applies topostUnpack
.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.
preUnpack
suggests the idea we need to some preparation to the source so that it can be unpacked by the unpack phase of the builder we are dealing with. Further, this unpack phase is, at least conceptually, a black box.Think in something like "oh the unpacker does not like dashes in the filename, let's change it to underscores first!" The
preUnpack
would change the filename, so that it can be passed to the black box.So I would follow the same as I said to postInstall:
+
instead ofor
.