-
-
Notifications
You must be signed in to change notification settings - Fork 15.5k
notmuch: extract optional dependencies #84008
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
Conversation
I believe the standard way of doing optional dependencies is to make them optional in the attrs (so |
I can do that for Do you see a way around that?
Absolutely. Will fix that. |
@@ -7,6 +7,8 @@ | |||
, emacs | |||
, ruby | |||
, which, dtach, openssl, bash, gdb, man | |||
, withDocs ? true |
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 having a different output for docs instead of disabling it?
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'm afraid I don't know what that means/how to do it ^_^
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.
You basically add:
outputs = [ "out" "doc" ];
Than it should move "$out/usr/share/doc" to "$doc" instead of "$out".
Having multiple outputs is a feature of nixpkgs and described in the nixpkgs manual here: https://nixos.org/nixpkgs/manual/#chap-multiple-output
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.
Something like this?
configureFlags = [ "--zshcompletiondir=${placeholder "out"}/share/zsh/site-functions" ]; | ||
configureFlags = [ | ||
"--zshcompletiondir=${placeholder "out"}/share/zsh/site-functions" | ||
"--mandir=${placeholder "doc"}" |
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.
Maybe this should go to man
output. Some people want to read the manpage without reading the developer documentation. Also the man
output automatically picks up the right files without an need for having to specify its path in configureFlags
.
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.
yeah I noticed right after pushing. Fixing it now
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
bash-completion # (optional) dependency to install bash completion | ||
emacs # (optional) to byte compile emacs code, also needed for tests | ||
ruby # (optional) ruby bindings | ||
bash-completion # (optional) dependency to install bash completion |
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.
Is this invoked during build, or made a runtime reference? If the former is the case, it'd need to be in nativeBuildInputs
.
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.
Hmm likely build only. Let me try
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.
Seems to work. I updated the PR
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.
Meh, I quickly tried by cross-compiling neomutt to aarch64, but this failed, as talloc
required for notmuch
currently fails to cross-compile.
I assume this is fine, we can always fix it up later.
Thanks! |
Just out of curiosity: In the original derivation, does |
AFAIK, it happened because |
Nix tracks runtime closures, and does that per output. Even if you'd add libreoffice to For this specific package, there's a single reference to
if I'm not exactly sure on how emacs integrates with notmuch works, and if moving |
|
`notmuch-emacs-mua` is used as the handler for `mailto:` links when other applications want to spawn the user's mail client. This will need to be propagated to the user's environment if they're using the standard notmuch client (i.e. notmuch.el).
Thanks for the explaination!
So if we'd move `notmuch-emacs-mua` to a separate `emacs` output and add
some release notes explaining it now needs to be obtained from the
`notmuch.emacs` output, this should be fine.
|
If you're splitting it, then the Emacs client itself should also be moved to that output to avoid confusion. |
On 20-04-04 12:42:52, Vincent Ambo wrote:
> So if we'd move `notmuch-emacs-mua` to a separate `emacs` output and add some release notes explaining it now needs to be obtained from the `notmuch.emacs` output, this should be fine.
If you're splitting it, then the Emacs client itself should also be moved to that output to avoid confusion.
You mean `$out/share/emacs`, right?
I don't see any other emacs-related things in `$out`…
|
On 14:54 04.04.20, Florian Klink wrote:
On 20-04-04 12:42:52, Vincent Ambo wrote:
>> So if we'd move `notmuch-emacs-mua` to a separate `emacs` output and add some release notes explaining it now needs to be obtained from the `notmuch.emacs` output, this should be fine.
>
>If you're splitting it, then the Emacs client itself should also be moved to that output to avoid confusion.
You mean `$out/share/emacs`, right?
I don't see any other emacs-related things in `$out`…
Just my 2 cents. Haven't actually opend the GH page for this PR so I
only got what GH decided to send via mail.
I don't know an example from the top of my head but I think for other
plugin systems we have code that basically does `plugin.someEditor or plugin`
to automatically convert a package that is a plugin for `someEditor` (or
`someSoftware`) to a plugin (or the path of the plugin).
Don't we have a similar system for emacs? If not, wouldn't that make
sense? I sounds better then having to ask each user update their
configuraiton just because some binary build also supports a plugin for
some editor. Also it should keep the domain knowledge (of where the
plugin code in the notmuch package is) to the notmuch package.
|
Seems like something @adisbladis would know. |
There seems to be |
Motivation for this change
I realized today that installing
neomutt
installsnotmuch
which installsemacs
which to me, usingneovim
, seems a bit wasteful :)I extracted the optional dependencies and put them behind a few package options. Using this as an overlay on my system works, but would be happy to discuss everything, from formatting to defaults of the optional parameters to testing/touching other derivations depending on this one, ...
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)