purcell/envrc

`void-function inheritenv` when `envrc-propagate-environment` is called

Closed this issue · 4 comments

hlissner commented

I get this error when envrc calls envrc-propagate-environment:

Debugger entered--Lisp error: (void-function inheritenv)
  inheritenv("/home/hlissner/projects/org/notes/daily/2020-11-14...")
  envrc-propagate-environment(#<subr shell-command-to-string> "/run/current-system/sw/bin/find -L \"/home/hlissner...")
  apply(envrc-propagate-environment #<subr shell-command-to-string> "/run/current-system/sw/bin/find -L \"/home/hlissner...")

Only way around it is to recompile envrc (via M-x byte-recompile-directory) after I've loaded inheritenv in the current session (with M-x load-library RET inheritenv).

I believe the cause is that this package doesn't load inheritenv at compile time, so the macro is unavailable to be expanded, causing it to be treated as a function call.

A (eval-when-compile (require 'inheritenv)) at the top of the package would fix it.

purcell commented

I don't think eval-when-compile is necessary here. require is eval-and-compile.

The latest version of envrc does (require 'inheritenv), so I think the problem you're reporting must have occurred in the ~24hrs while this was broken.

purcell commented

Ugh, sorry, my fix hadn't been properly pushed at the time, so I've been assuming everyone had it. In the meantime, it's just come in as #15. Apologies.

purcell commented

And, MELPA has built the new version.

hlissner commented

require is eval-and-compile

The rationale was: you only need inheritenv loaded at compile time (to expand the macro), and its expanded form doesn't use anything from inheritenv, so the library isn't needed at run time. It's a minor optimization though. In any case, it works perfectly now. Thanks for your prompt response (and for this package)!

  • 👍1