Hi, After Emacs started nagging me with the following IMPORTANT: please install Org from GNU ELPA as Org ELPA will close before Org 9.6 I set in init.el (setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/") ("nongnu" . "http://elpa.nongnu.org/nongnu/") ("melpa" . "http://melpa.org/packages/"))) and have (use-package org :ensure org-contrib) I moved the old-plus-contrig ELPA folder out the way. However, I now just get the built-in version of Org: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) Is this a problem use-package has with built-in packages, as described here https://github.com/jwiegley/use-package/issues/319 ? Or am I doing something wrong? Or do I just need to install via M-x list-packages (bearing in mind the caveat about not visiting an org file beforehand)? Cheers, Loris -- This signature is currently under construction.
On Wednesday, 9 Feb 2022 at 14:25, Loris Bennett wrote:
> Is this a problem use-package has with built-in packages, as described here
>
> https://github.com/jwiegley/use-package/issues/319
Yes, I think so.
What happens if you "M-x package-list-packages" and then install org
from there? (use "i" to request installation and then "x" to execute)
--
: Eric S Fraga, with org release_9.5.2-364-ge7ea95 in Emacs 29.0.50
Hi Eric,
Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Wednesday, 9 Feb 2022 at 14:25, Loris Bennett wrote:
>> Is this a problem use-package has with built-in packages, as described here
>>
>> https://github.com/jwiegley/use-package/issues/319
>
> Yes, I think so.
>
> What happens if you "M-x package-list-packages" and then install org
> from there? (use "i" to request installation and then "x" to execute)
Thanks, that did the trick. I was hoping that when I use the same
init.el on a different machine I wouldn't have to remember anything and
use-package would automatically install the latest version. Seemingly
not :-/
Cheers,
Loris
--
This signature is currently under construction.
>(use-package org >:ensure org-contrib) I believe `:ensure org-contrib` is no longer needed. I tend to use the org-mode from the package manager, but do not do it interactively from within emacs. Instead, which when I want to refresh org, I do from the command line: emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))" Also, early in my init.el, as extra level of precaution against getting the built-in org-mode, I ensure it never gets loaded: (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test #'string-match)) load-path) > >I moved the old-plus-contrig ELPA folder out the way. However, I now >just get the built-in version of Org: > >Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) > >Is this a problem use-package has with built-in packages, as described here > >https://github.com/jwiegley/use-package/issues/319 > >? Or am I doing something wrong? Or do I just need to install via M-x >list-packages (bearing in mind the caveat about not visiting an org file >beforehand)? > >Cheers, > >Loris > >-- >This signature is currently under construction. >
Loris, et al., > Thanks, that did the trick. I was hoping that when I use the same > init.el on a different machine I wouldn't have to remember anything and > use-package would automatically install the latest version. Seemingly > not :-/ this is maybe an appropriate time to insert a plug for straight.el: ---- https://github.com/raxod502/straight.el ---- though, in reality, it has its own rough edges. yremv ("your rough edges may vary" :). cheers, Greg
"Cook, Malcolm" <MEC@stowers.org> writes: >>(use-package org >>:ensure org-contrib) > > I believe `:ensure org-contrib` is no longer needed. Well, I would need it if I actually wanted anything from org-contrib, but I really have to check whether this is still the case. > I tend to use the org-mode from the package manager, but do not do it interactively from within emacs. Instead, which when I want to refresh org, I do from the command line: > > emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))" Is that necessary? Can't I just use the package manager to update Org along with any other packages? Or does the issue about not visiting and .org file before installing via the package manager apply to updates too? > Also, early in my init.el, as extra level of precaution against getting the built-in org-mode, I ensure it never gets loaded: > (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test #'string-match)) load-path) Interesting, although I would generally want at least some version of Org even if a more recent version is installed but somehow broken. >> >>I moved the old-plus-contrig ELPA folder out the way. However, I now >>just get the built-in version of Org: >> >>Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.1/lisp/org/) >> >>Is this a problem use-package has with built-in packages, as described here >> >>https://github.com/jwiegley/use-package/issues/319 >> >>? Or am I doing something wrong? Or do I just need to install via M-x >>list-packages (bearing in mind the caveat about not visiting an org file >>beforehand)? >> >>Cheers, >> >>Loris >> >>-- >>This signature is currently under construction. >>
Loris Bennett <loris.bennett@fu-berlin.de> writes:
> "Cook, Malcolm" <MEC@stowers.org> writes:
>
>>
>> emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))"
>
> Is that necessary? Can't I just use the package manager to update Org
> along with any other packages? Or does the issue about not visiting and
> .org file before installing via the package manager apply to updates
> too?
>
Even with updates, it is still important that no existing org
functionality has been loaded to avoid potential inconsistencies due to
mixed version installation. For updates within the same version (i.e.
bug fix updates), the risk is low, but may still result in an
inconsistent build.
Tim Cross <theophilusx@gmail.com> writes: >> Is that necessary? Can't I just use the package manager to update Org >> along with any other packages? Or does the issue about not visiting and >> .org file before installing via the package manager apply to updates >> too? >> > > Even with updates, it is still important that no existing org > functionality has been loaded to avoid potential inconsistencies due to > mixed version installation. For updates within the same version (i.e. > bug fix updates), the risk is low, but may still result in an > inconsistent build. It looks like there was an attempt to fix mixed compilation issue in package.el See https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c13baa10d55ec863d3ceaea48c6b2959ece98198 and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125 If I understand that thread correctly, package.el should not have issues with mixed compilation. Not so sure about straight.el and certainly it will not solve the problem when part of built-in Org is loaded before the newer Org version is added to the load-path. Best, Ihor
Hi Loris, > > I tend to use the org-mode from the package manager, but do not do it interactively from within emacs. Instead, which when I want to refresh org, I do from the command line: > > > > emacs -Q -batch -eval "(progn (require 'package) (package-initialize) (package-refresh-contents) (package-install 'org))" > > Is that necessary? Can't I just use the package manager to update Org > along with any other packages? Or does the issue about not visiting and > .org file before installing via the package manager apply to updates > too? AFAIK, what is necessary (though for reasons somewhat beyond my ken) is that org updates be installed in an environment in which no version of org has been loaded. You need some approach to ensure that. This is one such. Agreed it is heavy handed, but it suffices the need. I wish I could express the order dependencies in a reliable fashion with `use-package`. It *might* be the case that execution of the following snippet early enough in your init file is enough for `use-package` to "get it right"(tm). If you try this, let us know the outcome. > > Also, early in my init.el, as extra level of precaution against getting the built-in org-mode, I ensure it never gets loaded: > > (require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test #'string-match)) load-path) > > Interesting, although I would generally want at least some version of > Org even if a more recent version is installed but somehow broken. If you can code that logic in lisp, you can conditionally execute the provided snipped. /joke But I get your point. In my case, sometimes I want to run with a git pull from head of org repos rather than a package install. At such times I wind up editing my init file and use the `use-package`'s :load-path and :pin directives: :pin manual :load-path "~/.emacs.d/org-mode/lisp" ;; which was installed with: `cd ~/emacs.d && git clone https://git.savannah.gnu.org/git/emacs/org-mode.git && cd org-mode && make autoloads && make` ;; and can be updated with: `cd ~/emacs.d/org-mode && git pull && make autoloads && make` Point being that I have found that expressing the logic to cover every use case requires me to edit my init.el and interact with the command line "out of band", as it were. YMMV ~Malcolm
Ihor Radchenko <yantar92@gmail.com> writes:
> Tim Cross <theophilusx@gmail.com> writes:
>
>>> Is that necessary? Can't I just use the package manager to update Org
>>> along with any other packages? Or does the issue about not visiting and
>>> .org file before installing via the package manager apply to updates
>>> too?
>>>
>>
>> Even with updates, it is still important that no existing org
>> functionality has been loaded to avoid potential inconsistencies due to
>> mixed version installation. For updates within the same version (i.e.
>> bug fix updates), the risk is low, but may still result in an
>> inconsistent build.
>
> It looks like there was an attempt to fix mixed compilation issue in
> package.el See
> https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=c13baa10d55ec863d3ceaea48c6b2959ece98198
> and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125
>
> If I understand that thread correctly, package.el should not have issues
> with mixed compilation. Not so sure about straight.el and certainly it
> will not solve the problem when part of built-in Org is loaded before
> the newer Org version is added to the load-path.
>
Thanks for the info. However, I'm not confident that has addressed the
full issue. I note that patch is from 2014. There has certainly been a
number of people report mixed installation problems since that patch
would have been applied and part of their current version of package.el.
As you point out, we don't know what happens with other package managers
like straight.el and you are likely to get this issue if part of the
built-in version has been loaded before package.el attempts to load the
new version, so that might explain these later reports.
Would seem the best approach and simplest solution is still to ensure no
org functionality has been loaded before attempting an update.
On 09 February 2022 16:51, "Loris Bennett" <loris.bennett@fu-berlin.de> wrote:
> Thanks, that did the trick. I was hoping that when I use the same
> init.el on a different machine I wouldn't have to remember anything and
> use-package would automatically install the latest version. Seemingly
> not :-/
I had a similar issue in the recent past and was able to come up with a
solution using the built-in package.el. Not sure how to make it work
with use-package, but that at least seems to solve the issue of it not
installing the ELPA version.
Not really sure if the version installed is the one that Emacs actually
uses, though, I am on Emacs 28.0.91 and all of the built-in packages I
have are the same version as their ELPA counterpart, so Emacs seems to be
prioritizing the built-in version. It could be that this is only the
case because they're both the same version; and seem as I'm traveling
ATM I couldn't test it against Emacs 27, so it would be great if you
could check it.
Cheers,
--
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
On 10 February 2022 17:57, João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> wrote: > I had a similar issue in the recent past and was able to come up with a > solution using the built-in package.el. Not sure how to make it work > with use-package, but that at least seems to solve the issue of it not > installing the ELPA version. Forgot to add the link to my previous email, oops! https://lists.gnu.org/archive/html/emacs-orgmode/2022-02/msg00062.html -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Hi João,
João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> writes:
> On 09 February 2022 16:51, "Loris Bennett" <loris.bennett@fu-berlin.de> wrote:
>
>> Thanks, that did the trick. I was hoping that when I use the same
>> init.el on a different machine I wouldn't have to remember anything and
>> use-package would automatically install the latest version. Seemingly
>> not :-/
>
> I had a similar issue in the recent past and was able to come up with a
> solution using the built-in package.el. Not sure how to make it work
> with use-package, but that at least seems to solve the issue of it not
> installing the ELPA version.
>
> Not really sure if the version installed is the one that Emacs actually
> uses, though, I am on Emacs 28.0.91 and all of the built-in packages I
> have are the same version as their ELPA counterpart, so Emacs seems to be
> prioritizing the built-in version. It could be that this is only the
> case because they're both the same version; and seem as I'm traveling
> ATM I couldn't test it against Emacs 27, so it would be great if you
> could check it.
What exactly would you like me to test?
Cheers,
Loris
--
This signature is currently under construction.
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --] On 17 February 2022 16:00, "Loris Bennett" <loris.bennett@fu-berlin.de> wrote: > What exactly would you like me to test? I ended up not posting the link[1] I referred to in the first e-mail, but since then I got back home and tested the functions provided there seem to be doing what I expected. With it, I can force Emacs to download a built-in package from ELPA and use it, instead of the built-in version. I was afraid that I was only downloading it, but Emacs wasn't actually loading it, but I couldn't test it because I have Emacs 28.0.91, which contains the latest versions of all the built-in packages that are also in ELPA. Given that, I have compiled Emacs 27 and ran it with the attached init.el, and running M-x org-version tells me Org mode version 9.5.2 (9.5.2-gfbff08 @ .../.emacs.d/elpa/org-9.5.2/) It seems that calling my (require-package 'pkg 'force) is getting the latest ELPA version available for built-in packages and using that programatically, without having to use the Package List interface. Regards, -- João Pedro de Amorim Paula IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN) [-- Attachment #2: init.el --] [-- Type: application/emacs-lisp, Size: 1432 bytes --]
On 18 February 2022 18:32, João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> wrote:
> I ended up not posting the link[1] I referred to in the first e-mail,
Welp, seems like I did it again... But no harm done this time, all the
necessary code was attached anyway :P
Forgetfully,
--
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do Norte (UFRN)
Hi João,
João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> writes:
> On 18 February 2022 18:32, João Pedro de Amorim Paula <jpedrodeamorim@gmail.com> wrote:
>
>> I ended up not posting the link[1] I referred to in the first e-mail,
>
> Welp, seems like I did it again... But no harm done this time, all the
> necessary code was attached anyway :P
>
> Forgetfully,
Thanks for the code. I'll have a look at it.
Cheers,
Loris