0

I am a relative emacs-noob, but for a long time my emacs setup relying on use-package worked well. It still does, but I recently looked into using a few more packages and after following a trail of errors I found out that I can no longer access MELPA to upgrade/download/etc packages. Emacs fully works and doesn't complain until I want to do anything package management related.

I've narrowed it down to running M-x package-refresh-contents which gives me these messages:

Contacting host: melpa.org:443
Failed to download ‘melpa’ archive.
Contacting host: elpa.gnu.org:443
Failed to download ‘gnu’ archive.
Package refresh done
Failed to download ‘nongnu’ archive.

Which means I'm stuck with my old, local MELPA tree from the past and obviously can't get any new things working. Running the command after M-x toggle-debug-on-error gives me the following backtrace:

Debugger entered--Lisp error: (wrong-type-argument listp "/opt/homebrew/bin")
  signal(wrong-type-argument (listp "/opt/homebrew/bin"))
  package--with-response-buffer-1("https://melpa.org/packages/" #f(compiled-function () #<bytecode 0x156adc8adc58f9d3>) :file "archive-contents" :async nil :error-function #f(compiled-function () #<bytecode -0x20fd81f8bb468e1>) :noerror nil)
  package--download-one-archive(("melpa" . "https://melpa.org/packages/") "archive-contents" nil)
  package--download-and-read-archives(nil)
  package-refresh-contents()
  funcall-interactively(package-refresh-contents)
  call-interactively(package-refresh-contents record nil)
  command-execute(package-refresh-contents record)
  execute-extended-command(nil "package-refresh-contents" "package-refre")
  funcall-interactively(execute-extended-command nil "package-refresh-contents" "package-refre")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

But accessing MELPA with a browser or other way works:

curl -i https://melpa.org/packages/
HTTP/1.1 200 OK
Server: nginx
[...]

It seems to me like something changed/broke my homebrew backend and emacs can't find whatever it's using to access MELPA in /opt/homebrew/bin? I run MacOS and homebrew everything, using railwaycat/emacs-mac as my emacs provider:

GNU Emacs 28.2 (build 1, aarch64-apple-darwin21.6.0, Carbon Version 165 AppKit 2113.6) 
 of 2022-09-15

As it did work in the past, I do not believe it's an issue with my config, but for completeness, here's the relevant section of my init.el:

;; https://ianyepan.github.io/posts/setting-up-use-package/
(require 'package)
(add-to-list 'package-archives '("gnu"   . "https://elpa.gnu.org/packages/"))
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))

(package-initialize)

(unless (package-installed-p 'use-package)
  (package-refresh-contents)
  (package-install 'use-package))
(eval-and-compile
  (setq use-package-always-ensure t
    ; speedup startup time by only loading use-packages when needed
    use-package-always-defer t
    ; set to t for debugging 
    use-package-verbose nil
    use-package-expand-minimally t))

(eval-when-compile
  (require 'use-package))

Any help on where to look at, or how to get better logs on what exactly emacs is missing from my homebrew bins would be greatly appreciated!

4
  • 3
    Try with emacs -q -l min.el with a minimal init file that just sets up the package archives. I suspect that it's either something in your init file (bisect it to figure out what) or your current emacs session is curdled somehow: it's unclear where "/opt/homebrew/bin" is coming from.
    – NickD
    Apr 20, 2023 at 16:10
  • 2
    what @NickD said. check everywhere in your config you have /opt/homebrew/bin. you shouldn't really need it for anything except maybe (add-to-list 'exec-path "/opt/homebrew/bin"), and even that's not necessary for using packages.
    – nega
    Apr 20, 2023 at 17:35
  • Ah, thanks, this did solve the MELPA part! I had this in my config: (when (string-equal system-type "darwin") (setq exec-path (append exec-path '"/opt/homebrew/bin"))) commenting it resolves the issue. Now, I think I had needed that for aspell to work on mac, but I'll investigate further. I wonder why it messed up internals, though? Apr 20, 2023 at 20:06
  • 1
    Did you try restarting emacs? And setting exec-path as you do is wrong: you should use (add-to-list 'exec-path "/opt/homebrew/bin" t) to add the element to the end. The way you do it makes exec-path an improper list.
    – NickD
    Apr 21, 2023 at 14:15

1 Answer 1

1

According to your comment

;; I had this in my config:
(when (string-equal system-type "darwin")
    (setq exec-path (append exec-path '"/opt/homebrew/bin")))

You've "double quoted" the string "/opt/homebrew/bin". Drop the apostrophe, and things will work as you expect.

If you're not purposefully trying to re-order exec-path you may want to think about using add-to-list instead of doing an append-and-self-assign. add-to-list will prepend (by default) or append (optionally) to a list if the element does not already exist in the list. It's a handy way to keep lists like paths tidy.


Note that if you have added Homebrew to your path in your ~/.zshev then launching Emacs from Finder/Launchpad/Dock, via open -a Emacs, or a symlink or direct call in your terminal should all work as you expect without touching exec-path. That being said I do something like the following:

# ~/.zshenv
# make sure Finder/Launchpad can find Homebrew stuff
if [[ -x /opt/homebrew/bin/brew ]]; then
  export PATH=/opt/homebrew/bin:${PATH}
fi

# ~/.zshrc
# add Homebrew convenience vars, and add to PATH/INFOPATH/MANPATH 
eval $(brew shellenv)

and

;; ~/.emacs/init.el
;; exec-path, not strictly necessary, but doesn't hurt
;; load-path, use cmake's cmake-mode.el not emacs's
(cond ((string-match-p "aarch64-apple" system-configuration)
       (add-to-list 'load-path "/opt/homebrew/share/emacs/site-lisp/cmake")
       (add-to-list 'exec-path "/opt/homebrew/bin"))
      ((string-match-p "x86_64-apple" system-configuration)
       (add-to-list 'load-path "/usr/local/share/emacs/site-lisp/cmake")
       (add-to-list 'exec-path "/usr/local/bin")))
1
  • Thanks a lot for your in-depth answer and help! Yes, d'oh... I see the superfluous ' now... I tested around today and I did indeed not need the exec-path part at all. That's probably why it never triggered any errors. Apr 21, 2023 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.