Closed jsyjr closed 1 month ago
Unfortunately, elpaca is unable to clone that repository because it drops the trailing 'd' in '.emacs.d'.
This is by design. File suffixes are dropped because there are a number of elisp packages which are hosted in repositories which include a ".el" suffix. You can use the :repo recipe keyword to rename the repository locally. See the following test case:
elpaca | 02d97bf HEAD -> master, origin/master, origin/HEAD |
installer | 0.7 |
emacs | GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.43, cairo version 1.18.2) of 2024-09-12 |
git | git version 2.46.0 |
Side note: There are quite few compilation errors in the output due to the repository not being set up like a proper elisp package. You may be able to get Elpaca to work with someone's .emacs.d, but it's not the primary design goal.
Does that help?
Thanks for the prompt reply. And good to know the rationale for the by-design behavior.
I have been able to run your elpaca-test form successfully. The many errors you mentioned are expected. I will address them in due course.
Between your elpaca-test example and the :repo documentation plus some experimentation, I was able to determine that my ":host codeberg" construct, though undiagnosed, would never work (:source ends up being nil).
I have finally ended up with this working form:
(use-package my-swift-mode
:ensure (:repo "https://codeberg.org/woolsweater/.emacs.d.git"
:files (:default "*/*"))
:mode "\\.swift\\'"
)
Thanks - /john
Glad you were able to get something working.
I was able to determine that my ":host codeberg" construct, though undiagnosed, would never work (:source ends up being nil).
Could you clarify what you mean here? Where is :source
nil and what issue does that cause?
I have debug-on-error turned on. When I used the :host codeberg construct, I got a backtrace that included an empty :source value in numerous call frames near the top of the stack. I guessed (perhaps incorrectly) that the fact that elpaca's cache directory includes no codeberg entry might be the issue. That prompted me to try the :repo "full URL" construct.
On reviewing :host's documentation https://github.com/progfolio/elpaca/blob/master/doc/manual.md#host--fetcher :
A symbol or string representing the hosting service of the repository. Strings
are inserted in the URI verbatim.
the second sentence seems inaccurate. ':host github' surely inserts ' github.com', not verbatim 'github'. Does ':host codeberg' insert incorrectly 'codeberg.com' or does elpaca know enough to insert ' codeberg.org'?
/john
On Mon, Sep 23, 2024 at 4:48 PM Nicholas Vollmer @.***> wrote:
Glad you were able to get something working.
I was able to determine that my ":host codeberg" construct, though undiagnosed, would never work (:source ends up being nil).
Could you clarify what you mean here? Where is :source nil and what issue does that cause?
— Reply to this email directly, view it on GitHub https://github.com/progfolio/elpaca/issues/361#issuecomment-2369352807, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6DG43UNIKLJJMSQWL7EDZYB5B5AVCNFSM6AAAAABOVEYTIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRZGM2TEOBQG4 . You are receiving this because you modified the open/close state.Message ID: @.***>
-- John Yates 505 Tremont St, #803 Boston, MA 02116
I guessed (perhaps incorrectly) that the fact that elpaca's cache directory includes no codeberg entry might be the issue.
The cache directory is mostly for storing computed recipes from various ELPAs. For example, melpa.eld
will include recipes which specify :fetcher codeberg
.
the second sentence seems inaccurate.
The full second sentence is:
Strings are inserted in the URI verbatim.
When a symbol is used, such as github
or codeberg
, the appropriate host should be computed. e.g. coderberg
mapping to "codeberg.org". I plan on making the symbols more configurable in the future and will add more on that to the manual once it is implemented.
Thanks for the prompt, informative follow up.
And since I don't believe that I have said it yet, thank you so much for elpaca. I love it.
/john
On Thu, Sep 26, 2024 at 8:24 AM Nicholas Vollmer @.***> wrote:
I guessed (perhaps incorrectly) that the fact that elpaca's cache directory includes no codeberg entry might be the issue.
The cache directory is mostly for storing computed recipes from various ELPAs. For example, melpa.eld will include recipes which specify :fetcher codeberg.
the second sentence seems inaccurate.
The full second sentence is:
Strings are inserted in the URI verbatim.
When a symbol is used, such as github or codeberg, the appropriate host should be computed. e.g. coderberg mapping to "codeberg.org". I plan on making the symbols more configurable in the future and will add more on that to the manual once it is implemented.
— Reply to this email directly, view it on GitHub https://github.com/progfolio/elpaca/issues/361#issuecomment-2376806689, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ6DGY7VHMOT45DKGTHDZDZYP4HBAVCNFSM6AAAAABOVEYTIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWHAYDMNRYHE . You are receiving this because you modified the open/close state.Message ID: @.***>
-- John Yates 505 Tremont St, #803 Boston, MA 02116
And thank you for the kind words. Glad you're finding Elpaca useful.
Confirmation
Elpaca Version
Elpaca 7b5e269 grafted, HEAD -> master, origin/master, origin/HEAD installer: 0.7 emacs-version: GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin23.6.0, NS appkit-2487.70 Version 14.6.1 (Build 23G93)) of 2024-09-08 git --version: git version 2.39.5 (Apple Git-154) Elpaca 7b5e269 grafted, HEAD -> master, origin/master, origin/HEAD installer: 0.7 emacs-version: GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin23.6.0, NS appkit-2487.70 Version 14.6.1 (Build 23G93)) of 2024-09-08 git --version: git version 2.39.5 (Apple Git-154)
Operating System
MacOS version 15.0
Description
I am trying to follow Josh Caswell's "swifter" work. In my emacs .init.el I use use-package, elpaca and elpaca-use-package. My stanza to install Josh's my-swift-mode looks like this:
Unfortunately, elpaca is unable to clone that repository because it drops the trailing 'd' in '.emacs.d'.