fix(lib): dependence on hash-table insertion order

Yes, yes. I did a stupid here. I depend on the order of a hash table,
and sure enough, that came back to bite me when that changed internally
in Emacs 29. In practice, this meant packages were getting
installed/rebuilt in reverse order, which, besides some odd output
during 'doom sync' for users on 29+, didn't pose any overt issues, but
may have caused strange, inexplicable byte-code warnings/errors.

But, rather than do the smart thing and *not* do this, I do the next
best thing: procrastinate! Because the solution is non-trivial (I don't
control the hash table in question) and this is precisely the sort of
technical debt I've fixed in v3, and I'd really, *really* rather beat my
head on that wall, rather than this one.
This commit is contained in:
Henrik Lissner
2025-09-22 22:19:00 -04:00
parent 4f62b503b9
commit 093488fcb7

View File

@@ -415,7 +415,10 @@ also be a list of module keys."
(unless (or (null local-repo) (unless (or (null local-repo)
(eq type 'built-in)) (eq type 'built-in))
(push recipe recipes)))) (push recipe recipes))))
(nreverse recipes))) ;; FIXME: Depending on a hash table's load order? Straight to jail.
(if (< emacs-major-version 29)
(nreverse recipes)
recipes)))
;;;###autoload ;;;###autoload
(defun doom-package-homepage (package) (defun doom-package-homepage (package)