GNU bug report logs - #48452
28.0.50; flymake for elisp does not respect `load-path`

Previous Next

Full log

Message #37 received at 48452 <at> debbugs.gnu.org (full text, mbox):

From: Max Brieiev <max.brieiev <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 48452 <at> debbugs.gnu.org
Subject: Re: bug#48452: 28.0.50; flymake for elisp does not respect `load-path`
Date: Fri, 15 Jul 2022 14:53:53 +0300

João Távora <joaotavora <at> gmail.com> writes:

> But it could make sense to add ~/.emacs.d/elpa/* to the variable, if the
> package you're developing somewhere else has a dependency on other Elpa
> packages.

Yes, to me it seems very common to have a depandency on an Elpa
package, so I was wondering why flymake was complaining about requiring
installed package.

> Or maybe, Max, you can just set this variable it in your file-local
> variables or the dir-locals.el of the package you're developing.

This could work, but doesn't it mean that with each new version of a
dependency, I'll have to change my dir-locals.el, because the version of
the installed package is part of its file path?

> Anyway, because the directories under ~/.emacs.d/elpa are somewhat
> special and/or security-vetted it _could_ make sense to add them to
> the default value of the variable. This would amount to more or less
> the same as calling the underlying process with `-f
> package-initialize` I think.
>
> But I'm still not sure this should be the default, or merely an option
> to the flymake-elisp-byte-compile backend.  I think the second is
> safer.

Both possibilities are fine to me.

Another option could be to parse the header section of the current
buffer for `Package-Requires:' clause, and then automatically add listed
dependencies to the `elisp-flymake-byte-compile-load-path'.

In this case, flymake would still had operated in quite restricted
environment, but at the same time it'd recognize package dependencies.

Would that make sense?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.