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

How to install package dependent on external artifact like mu4e #152

Open
brsvh opened this issue Jan 27, 2024 · 4 comments
Open

How to install package dependent on external artifact like mu4e #152

brsvh opened this issue Jan 27, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@brsvh
Copy link

brsvh commented Jan 27, 2024

Recently, I am trying to incorporate mu4e into my configuration, but I don't know how build it by Twist.

The building of mu4e is dependent on the artifacts of mu.

For example, as build by nixpkgs elispPackages.

https://github.com/NixOS/nixpkgs/blob/b9c6b11eafbb693c3d9d820bea1636a51c87b2a5/pkgs/applications/editors/emacs/elisp-packages/manual-packages/mu4e/default.nix#L7-L33

I attempted to independently build its Emacs Lisp portion, but it appears that there are many missing components that I am unsure how to address. For example, mu-guile and a mu4e-config.el generated from the template.

https://github.com/djcb/mu/blob/62f0a9a902031d172e03e8caaaad013a1798749f/mu4e/meson.build#L19-L27

I am interested in understanding the methods available for extracting the mu output and integrating it with twist. Alternatively, are there other reproducible build strategies?

@akirak
Copy link
Member

akirak commented Jan 27, 2024

I am interested in understanding the methods available for extracting the mu output and integrating it with twist

emacsTwist accepts inputOverrides which can be used to moderate the input of a package. It is originally meant to temporarily work around upstream issues, but it can be used to permanently override the source (example).

In this case, you could use this:

emacsTwist {
  ...
  inputOverrides = {
    mu4e = _: _: {
      src = nixpkgs.mu.mu4e;
    };
  };
}

It seems that mu4e is not registered to any of GNU/NonGNU ELPA and MELPA, so you'll have to define a recipe for yourself (which I assume you have been already doing).

@akirak
Copy link
Member

akirak commented Jan 28, 2024

You can browse the content of nixpkgs.mu.mu4e by pasting the output of the following command into Emacs dired/find-file:

nix build nixpkgs#mu.mu4e --print-out-paths

and the MELPA recipe should be

(mu4e :fetcher github :repo "djcb/mu"
  :files "share/emacs/site-lisp/mu4e/*.el")

Only :files field matters here, as the repository location will be overridden by inputOverrides above.

If you encounter a further problem with building mu4e, please report it in this ticket.

@brsvh
Copy link
Author

brsvh commented Jan 28, 2024

I appreciate your help, this way works fine within my configuration.

However, the MELPA Recipe appears somewhat peculiar, as we do not require a definitive upstream repository after overriding.

Furthermore, should we consider adding a local store or nixpkgs as an optional pseudo fetcher backend for the elisp-helpers MELPA parser? e.g., support a recipe like:

(mu4e :fetcher nixpkgs :package "mu.mu4e" :files ("**/*.el"))

It is merely a casual remark, it is anticipated that there will be limited applications for it.

@akirak
Copy link
Member

akirak commented Jan 28, 2024

Mu4e is quite an exceptional case. It is known to many Emacs users but unavailable from any of the popular registries.

I am unwilling to add extra fetchers that are not supported by MELPA. A better way to support mu4e (and possibly some other manual packages in nixpkgs) would be to allow the user to define a custom registry in Nix (like where each package just takes files from a Nix path), so the user won't have to define recipes for his/her custom packages. Maybe I will add the functionality in the future.

@akirak akirak added the enhancement New feature or request label Mar 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants