search

radian-software / straight.el

🍀 Next-generation, purely functional package manager for the Emacs hacker.
MIT License
2.72k stars 150 forks source link

Why does straight sometimes rebuild org? #1019

Open WorldsEndless opened 1 year ago

WorldsEndless commented 1 year ago

With the notorious orgmode updates and breakages, combined with the amount that I depend upon orgmode, I am trying to just stick with the built in version and not ever build it. As such, my Straight orgmode invocation looks like this:

(use-package org
:straight (:type built-in)

Nonetheless, some packages seem to cause org to "build" and use a straight version. One of these packages is elfeed-org, which, other than its name, doesn't make any mention of org in my use-package definition: no :after or any other mention. Is there some way I can prevent other packages from causing a Straight org build? Why could this be happening?

(use-package elfeed-org
  :after elfeed  
  :config
  (elfeed-org)
  (setq rmh-elfeed-org-files (list "~/org/elfeed.org")))
progfolio commented 1 year ago

The built-in version is loaded with the following test case:

Test Case ```emacs-lisp (straight-bug-report :post-bootstrap (straight-use-package '(org :type built-in)) (straight-use-package 'elfeed-org) (org-version nil 'full 'message)) ```
Output ```emacs-lisp Bootstrapping straight.el... Bootstrapping straight.el...done Looking for gnu-elpa-mirror recipe → Cloning melpa... Looking for gnu-elpa-mirror recipe → Cloning melpa...done Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror... Looking for nongnu-elpa recipe → Cloning gnu-elpa-mirror...done Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa... Looking for emacsmirror-mirror recipe → Cloning nongnu-elpa...done Looking for emacsmirror-mirror recipe → Cloning el-get... Looking for emacsmirror-mirror recipe → Cloning el-get...done Looking for straight recipe → Cloning emacsmirror-mirror... Looking for straight recipe → Cloning emacsmirror-mirror...done Building straight... Building straight...done Test run with version: prerelease (HEAD -> develop, origin/develop) b89a0f7 2022-11-26 Cloning elfeed-org... Cloning elfeed-org...done Building elfeed-org... Building elfeed-org → Cloning elfeed... Building elfeed-org → Cloning elfeed...done Building elfeed-org → Building elfeed... Building elfeed-org → Building elfeed...done Building elfeed-org → Cloning dash.el... Building elfeed-org → Cloning dash.el...done Building elfeed-org → Building dash... Building elfeed-org → Building dash...done Building elfeed-org → Cloning s.el... Building elfeed-org → Cloning s.el...done Building elfeed-org → Building s... Building elfeed-org → Building s...done Building elfeed-org... Building elfeed-org...done Org mode version 9.5.5 (release_9.5.5 @ /usr/share/emacs/30.0.50/lisp/org/) Packages: "straight" n/a develop b89a0f7 2022-11-26 "org-elpa" n/a n/a "melpa" n/a master 85c1dbae 2022-11-30 "gnu-elpa-mirror" n/a master 059e876 2022-11-27 "nongnu-elpa" n/a main b0bf1871b0 2022-11-27 "el-get" melpa master caf80e20 2022-11-24 "emacsmirror-mirror" n/a master cae49f7 2022-11-22 "elfeed-org" melpa master 3242ec0 2022-11-18 "elfeed" melpa master 162d7d5 2021-08-23 "dash" melpa master 3df46d7 2022-10-13 "s" melpa master e957dcb 2022-09-02 ```

Is your declaration for Org mode after your declaration for elfeed-org or any other package which requires Org as a dependency? If so, you need to move it before them. Otherwise Org is being installed as a dependency of a package and that version is being loaded.

You can use M-x straight-dependents org to list installed packages which depend on Org. You can also try adding the following to the beginning of your init file to hit the debugger once Org is loaded. The backtrace will show exactly who requires Org:

(eval-after-load "org" '(debug))
WorldsEndless commented 1 year ago

elfeed-org does indeed come before the orgmode section of my init file, because I've alphabetized my package use. I hoped one of the benefits of straight was that the order of my packages didn't matter. Is there some way I can use :after to accomplish this order-agnostic feature, or is the problem with alphabetizing my dependencies?

progfolio commented 1 year ago

I hoped one of the benefits of straight was that the order of my packages didn't matter.

The order of installation matters due to dependencies.

Is there some way I can use :after to accomplish this order-agnostic feature, or is the problem with alphabetizing my dependencies?

use-package's :after keyword won't help here, because it is concerned with loading packages (they are already installed by straight at that point).

One possible solution is to use Org's noweb syntax to organize your packages in whichever order you prefer and have them tangle in the appropriate order so that packages are installed properly.

https://orgmode.org/manual/Noweb-Reference-Syntax.html

chriselrod commented 1 year ago

There is no eglot-version, so I'm not sure how to adapt the org test case to eglot, but I have a similar problem, despite having eglot above eglot-jl in my init.el:

Package eglot is dependency.

     Status: Installed in ‘eglot-20221008.1019/’,
             shadowing a built-in package (unsigned).
    Version: 20221008.1019
     Commit: 5c7dfd40412f5086c56378aab21b6555385191d3
    Summary: Client for Language Server Protocol (LSP) servers
   Requires: emacs-26.1, jsonrpc-1.0.14, flymake-1.2.1, project-0.3.0, xref-1.0.1, eldoc-1.11.0, seq-2.23
Required by: eglot-jl-20211208.359
    Website: https://github.com/joaotavora/eglot
   Keywords: convenience languages 
 Maintainer: João Távora <joaotavora@gmail.com>
     Author: João Távora <joaotavora@gmail.com>
Other versions: 1.9 (gnu), 1.10 (builtin).

I wanted to use 1.10 (builtin), but I'm getting one from the archive (which is probably less up to date?). I'm on a recent emacs master.

> emacs --version
GNU Emacs 30.0.50
Development version 57e363a4514b on master branch; build date 2022-12-31.
progfolio commented 1 year ago

@chriselrod: M-x straight-dependents eglot should return a list of packages straight has installed which depend on eglot. Check to see if you are installing any of those prior to eglot. If you want the built-in version, you can add :type built-in to eglot's recipe. If neither of the above work, please share your init file if possible. I can take a look to see what may be causing this.

chriselrod commented 1 year ago

According to straight-dependents, eglot-jl is the only dependent of eglot. I am installing it after `eglot.

I do have :type built-in in eglot's recipe: https://github.com/chriselrod/configdir/blob/3116c73c97e66f244234a8696df1a7179b2df8bf/emacs/init.el#L102-L112 My init.el is here.

I tried this on 3 different computers. One of them used the built-in eglot, the other two did not. I am guessing that two of them had already installed the other eglot version, and that it isn't updating/switching.

progfolio commented 1 year ago

Try the following:

chriselrod commented 1 year ago

M-x straight-normalize-package eglot

It won't let me do this. It keeps autocompleting to eglot-jl on RET. I also just noticed that the version of eglot being used is in ~/.emacs.d/elpa, rather than ~/.emacs.d/straight/repos.

FWIW, I did straight-normalize-all and restarted emacs, and still have the elpa eglot.

chriselrod commented 1 year ago

FWIW https://github.com/radian-software/straight.el/issues/663 "2." (setq package-user-dir nil) seemed to break something, e.g. C-h P threw an error. "1.", deleting ~/.emacs.d/elpa worked.

raxod502 commented 1 year ago

Yeah, if you have ~/.emacs.d/elpa available, then it will be used by Emacs, unless you (setq package-enable-at-startup nil) in early-init.el. This is an Emacs feature and unfortunately there is not much we can do about it, besides signal a warning. I have filed https://github.com/radian-software/straight.el/issues/1036 to track this.

Does this solve the issue or is there more we can do?