[Bug/Support]: Elpaca unable to resolve package repo name conflicts #499
Description
Confirmation
- I have checked the documentation (README, Wiki, docstrings, etc)
- I am checking these without reading them.
- I have searched previous issues to see if my question is a duplicate.
Elpaca Version
Elpaca b5ef5f1 grafted, HEAD -> master, origin/master, origin/HEAD
installer: 0.11
emacs-version: GNU Emacs 30.2 (build 2, aarch64-apple-darwin24.6.0, NS appkit-2575.70 Version 15.7 (Build 24G222))
of 2025-09-25
git --version: git version 2.52.0
Operating System
Doesn't matter.
Description
When I was installing Claude Code IDE, I found that it depends on a package called web-server, which failed to install, even though Elpaca has figured out that the repo name conflicts with another package called simple-httpd, which is required by Jupyter. Upon detection of repo name conflict, Elpaca was able to suffix the clone's location on disk with the host and the username, but the package still failed to install with this message found in the logs.
[2025-12-13 12:21:21] $git clone https://github.com/eschulte/emacs-web-server.git /Users/wyuenho/.emacs.d/elpaca/repos/emacs-web-server.github.eschulte/
[2025-12-13 12:21:21] fatal: destination path '/Users/wyuenho/.emacs.d/elpaca/repos/emacs-web-server.github.eschulte' already exists and is not an empty directory.
[2025-12-13 12:21:21] fatal: destination path '/Users/wyuenho/.emacs.d/elpaca/repos/emacs-web-server.github.eschulte' already exists and is not an empty directory.
When I inspected the suffixed clone, I found that Elpaca has deleted every file in it and staged all the deletion.
❯ git st
On branch master
Your branch is up to date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
deleted: .elpaignore
deleted: .github/workflows/test.yml
deleted: .gitignore
deleted: COPYING
deleted: Makefile
deleted: NOTES
deleted: README
deleted: doc/.gitignore
deleted: doc/Makefile
deleted: doc/doclicense.texi
deleted: doc/gpl.texi
deleted: doc/web-server.texi
deleted: examples/000-hello-world.el
deleted: examples/001-hello-world-utf8.el
deleted: examples/002-hello-world-html.el
deleted: examples/003-file-server.el
deleted: examples/004-url-param-echo.el
deleted: examples/005-post-echo.el
deleted: examples/006-basic-authentication.el
deleted: examples/007-org-mode-file-server.el
deleted: examples/008-file-upload.el
deleted: examples/009-web-socket.el
deleted: examples/010-current-buffer.el
deleted: examples/011-org-agenda.el
deleted: examples/012-search-bbdb.el
deleted: examples/013-org-export-service.el
deleted: examples/014-org-json.el
deleted: examples/015-auto-mode-server.el
deleted: examples/016-content-encoding-gzip.el
deleted: examples/017-transfer-encoding-chunked.el
deleted: examples/018-web-shell.el
deleted: examples/018-web-shell.html
deleted: examples/018-web-shell.js
deleted: web-server-status-codes.el
deleted: web-server-test.el
deleted: web-server.el
The only way to get around this problem is to explicitly define one of the conflicting dependencies with a separate use-pacakge declaration, which resulted in Elpaca renaming the other simple-httpd's repo instead of the one in question, which really is called web-server in the Melpa recipe.
(use-package web-server
:ensure (web-server :fetcher github :repo "eschulte/emacs-web-server"))This suggests to me that during package dependency resolution, some code paths in Elpaca simply uses a simple recipe name to repo name mapping instead of a recipe name to fully qualified repo name mapping, while others use the fully qualified mapping, which causes this inconsistent unintuitive behavior.