-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't use eglot with latest Emacs & straight, due to project.el location #1146
Comments
Huh... interesting... let me have a look at what is going on there. Thanks for the ideas on debugging. |
Ok, I see that Maybe there is an edge case when the same package is provided from multiple locations, that is not taken into account properly by one system or the other. I'll build a more recent Emacs snapshot and try it out since I have not used this function before. |
Yes, okay, this makes sense. The issue is that https://github.com/bbatsov/projectile/blob/0163b335a18af0f077a474d4dc6b36e22b5e3274/projectile.el#L9 So https://github.com/joaotavora/eglot/blob/db91d58374627a195b731a61bead9b4f84a7e4bc/eglot.el#L10 Which causes I think the correct solution here is for |
We can leave this issue open until Projectile is updated to declare the dependency, and new users will not encounter this problem anymore. The workaround is as you observed; |
Forgive the intrusion, but I wonder if this is another instance of the problem reported at these issues, relating to a |
Yes, look here: alphapapa/burly.el#64 (comment) The repo at https://github.com/emacs-straight/map.git is importing |
It may indeed be related, but not quite the same. In my case both project.el versions are identical; it's the new |
We could prevent this and similar issues if straight didn't install external versions of core packages unless they were explicitly requested by the user. (defcustom elpaca-ignored-dependencies (mapcar #'car package--builtin-versions)
"List of IDs which are not installed unless the user explicitly requests them."
:type '(repeat symbol))
I agree this isn't great. I'm currently struggling financially, so I won't have time to implement any of the above for now. Once I can I will. |
Take care, I will continue triaging issues with the time that I have available, never feel obligated to spend time you don't have.
Ugh... this is really making it sound like we may actually need to properly support package version numbers. Because we really do want to install an external version of a package when the version shipped with Emacs is insufficiently recent to satisfy a dependency. But of course then if that is determined after the built-in version was already loaded, we are stuck again... I think you're right and disabling built-in packages by default is the right solution, even if it will be disruptive. We can implement it in a way that will signal a warning on first use, perhaps. Or make it as an opt-in feature, and report a warning when a package is added to I'll add the latter idea to my to-do list, to resolve that long-standing issue. And then Nicholas' idea about installing built-in packages only when requested. |
In case anybody runs into this issue and the original author's solution doesn't work (as it did not for me). You can also do this: (use-package straight
:custom
;; add project and flymake to the pseudo-packages variable so straight.el doesn't download a separate version than what eglot downloads.
(straight-built-in-pseudo-packages '(emacs nadvice python image-mode project flymake))
(straight-use-package-by-default t)) Which I gleaned from this comment by @raxod502 #551 (comment) eglot starts up as expected now. I am using Emacs 29.3 |
I ended up having to add |
You can check the revision in I don't believe GNU ELPA tells you which commit of a repository was used to build a particular package version, which is part of the reason I don't like it. You can probably get a good enough idea by extracting the timestamp embedded in the version number and checking to see where in the upstream commit history that fell. |
I install eglot via straight, and it's been working fine for a long time, until I just updated to the latest emacs master branch and pulled all the latest straight packages. Now emacs starts OK, but when I invoke
eglot
I get an error: "funcall: Feature provided by other file: project". This comes fromrequire-with-check
which looks to see if the featureproject
was loaded, usingload-history
. In my case,load-history
does not contain `project.In fact just calling
(require-with-check 'project)
fails with the same error. I think it's using the built-in version rather than what's loaded fromstraight
.I checked, and the built-in version is byte-for-byte identical with the version in
straight/repos
, but I thinkrequire-with-check
checks the file path.I also deleted straight.el's copy of the
project
repo and restarted, and straight clones it again, but I still get the error.If I debug into
require-with-check
, I see it callslocate-file
onproject
inload-path
and that returns~/.config/emacs/straight/build/project/project.elc
but that is not found inload-history
. That only contains "/Applications/Emacs.app/Contents/Resources/lisp/progmodes/project.elc" (or similar on Windows).I looked at #551 and other related issues, but they don't seem quite the same.
Here's a test case. Load this file into an
emacs -Q
session:and you'll see the error.
If you add
(use-package project)
before projectile, then it works OK.The text was updated successfully, but these errors were encountered: