cannot update melpa `M-x package-refresh-contents`

Question

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!

Answer 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")))