So if this works for people I'm not against merging it, but I think the problem is a little deeper than just mu4e. There are quite a lot of Emacs derivations that will put themselves in subdirectories of site-lisp like JDEE for instance. Something like normal-top-level-add-subdirs-to-load-path is probably needed in site-start.el

@matthewbauer I agree. Additionally, moving all emacs-lisp files into share/emacs/site-lisp/ will cause name collisions sooner or later. Anyway: we solve the problem by its root, I'd suggest to merge this work-around.

What do the maintainers think? @antono @the-kenny @peterhoeg

Are you sure it's not the same as #18146 (comment) ?

Are you sure it's not the same as #18146 (comment) ?

I can confirm than on NixOS with emacs and mu4e installed from nix-env, emacs -q (not -Q) is unable to find mu4e when (require)d. In my config, I use the following bit of magic to correctly locate mu4e:

(eval-and-compile (let ((mu4epath
                          (concat
                           (file-name-directory
                            (file-truename
                             (executable-find "mu")))
                           "../share/emacs/site-lisp/mu4e")))
                     (when (and
                            (string-prefix-p "/nix/store/" mu4epath)
                            (file-directory-p mu4epath))
                       (message "Adding %s to load-path" (file-truename mu4epath))
                       (add-to-list 'load-path (file-truename mu4epath)))))

It works because only mu4e is concerned, but probably wouldn't scale well.

@matthewbauer is right. The correct solution is to adapt our site-start.el used in our emacs derivation. It does the following right now:

;;; NixOS specific load-path
(setq load-path
      (append (reverse (mapcar (lambda (x) (concat x "/share/emacs/site-lisp/"))
                               (split-string (or (getenv "NIX_PROFILES") ""))))
              load-path))

We should extend it to traverse one (or more?) levels into subdirectories and add them to load-path too.

Note that this file isn't evaluated when Emacs is either started via -q or -Q (which is expected).

I'm closing this pull-request. Primarily, because this is not the good solution. Secondly, I should not have used my master-branch because it pushed another unrelated commit to it.

Does anybody want to implement the changes in site-start.el and create a pull-request? I can do it, too.

I closed this PR (because it only solved the symptoms instead of the root problem) and created an issue for the root problem at #33412.