Re: Multiple versions of Org in load-path problem

[Tom Gillespie]

> I don't think there is any safe way to install an updated version of
> org-mode other than

I don't know whether it counts as safe, but since I don't see it
mentioned anywhere else in the thread you can do the following.

(require 'package)
(unless package--initialized
  (package-initialize))
(assq-delete-all 'org package--builtins)
(assq-delete-all 'org package--builtin-versions)
(package-install 'org)

RE: Multiple versions of Org in load-path problem

[Cook, Malcolm]

> Adding this to bug #59882
> 
> "Michel Schinz"  writes:
> 
> > Just for the record, I also ran into problems when installing Org 9.6
> > using Emacs' package system on top of an older version that came with
> > Emacs. If I tried to install it as usual (M-x list-packages, then
> > install the package from there), I had errors during compilation
> > related to `org-assert-version`, and then if I restarted Emacs, I
> > would get a fatal error in an unrelated package.
> >
> > I managed to solve that problem by:
> > 1. uninstalling Org 9.6 and exiting Emacs, 2. starting Emacs with -q,
> > 3. installing Org 9.6 from there (using M-x list-packages as usual),
> > 4. restarting Emacs.
> 
> Interesting!  I tried this (essentially) and it worked for my case.  In my 
> case, I
> had a built-in Org-9.3 and I was trying to use list-packages to install 
> Org-9.6. I
> checked that using -q still added Org-9.3 to the load-path, but, since Org
> wasn't loaded, the install via list-packages worked.
> 
> The question is what's the proper way of doing this without '-q'?
> 
> > I'm not sure this is related to your problem, or whether that helps
> > (but I hope it does)...
> 
> I think it does.
> 
> Side note:
> 
> In my testing, I found a strange case where, in *scratch*, I get:
> 
> (message "%s" org-version)
> ;; Error undefined
> ;; Do 'C-h v org-version'
> (message "%s" org-version)
> 9.3
> 
> So, 'describe-variable' on org-version causes Org to be loaded?!?  [Cook, 
> Malcolm] 

Yes.  See 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload-by-Prefix.html

But it will NOT be autoloaded if you first:

(clrhash  definition-prefixes)

HTH & YMMV,

Malcolm

> Why do I
> have a feeling this is related to this bug?

Yeah, I'm not sure what you consider the bug to be now.  Remind me?

> 
> --
> David Masterson

Re: Multiple versions of Org in load-path problem

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Tim Cross  writes:

> David Masterson  writes:
>
>> Tim Cross  writes:
>>
>>> David Masterson  writes:
>>>
 "Michel Schinz"  writes:

> Just for the record, I also ran into problems when installing Org 9.6
> using Emacs' package system on top of an older version that came with
> Emacs. If I tried to install it as usual (M-x list-packages, then
> install the package from there), I had errors during compilation related
> to `org-assert-version`, and then if I restarted Emacs, I would get a
> fatal error in an unrelated package.
>
> I managed to solve that problem by:
> 1. uninstalling Org 9.6 and exiting Emacs,
> 2. starting Emacs with -q,
> 3. installing Org 9.6 from there (using M-x list-packages as usual),
> 4. restarting Emacs.

 Interesting!  I tried this (essentially) and it worked for my case.  In
 my case, I had a built-in Org-9.3 and I was trying to use list-packages
 to install Org-9.6. I checked that using -q still added Org-9.3 to
 the
 load-path, but, since Org wasn't loaded, the install via list-packages
 worked.

 The question is what's the proper way of doing this without '-q'?

This is what is in my 'init.el' file -

=
;;; init.el --- sharon's config -*- eval: (read-only-mode 1) -*-
;; Make sure that Git version of Org mode is being loaded instead of the 
built-in version.
;;; (add-to-list 'load-path (expand-file-name 
"/home/boudiccas/.emacs.d/elpa/org-9.5.5"))
(add-to-list 'load-path (expand-file-name 
"/home/boudiccas/.emacs.d/elpa/org-9.6"))
(add-to-list 'load-path (expand-file-name 
"/home/boudiccas/git/org-contrib/lisp"))

(require 'package)
(setq package-enable-at-startup nil)
(package-initialize)

(require 'ob-tangle)
(org-babel-load-file "/home/boudiccas/.emacs.d/config22-2.org")
=

And the first thing that is loaded is org-9.6 *before* anything else! And you 
could equally have org-mode loading from a git repository on your hard drive, 
just by changing the filepath.

Super-easy without having to faff about with 'emacs -q' etc.

And as you can see I'm using org-9.6 from elpa, and I didn't move over to it 
until this morning, so far so good.  

Thanks
  Sharon.  
  
>>
>> [...]
>>
>>> I don't think there is any safe way to install an updated version of
>>> org-mode other than
>>>
>>> 1. Use the -q approach outlined above
>>
>> Thinking about it, this only works if Org is in elpa as melpa (etc.) are
>> not added to package-archives.  You'd have to do some handwritten elisp
>> out of *scratch* to setup package-archives if Org-9.6 was still coming
>> out of melpa. That's why this can only be labeled as a hack and not a
>> solution.
>>
>
> Well, yes, if your going to use this technique to load a package which
> is not in the default package archives you would need to add that
> archive first. People who use this technique often just have a
> 'update.el' file which they load/evaluate when starting Emacs with -q. 
>
>
>>> 2. Craft your init.el file such that org functionality is only loaded
>>> when explicitly requested and always update as the first action after
>>> starting emacs.
>>
>> In this case, something happened in package-install when trying to
>> install Org-9.6 with a built-in Org-9.3.  During the compilation check
>> (.el -> .elc) many files failed because the new 'org-assert-version'
>> macro was not defined.  Sort of like, after package-install started
>> working on Org-9.6, org-macs.el (where org-assert-version should be) got
>> loaded *before* the new load-path had been set causing it to load the
>> old one from 9.3.  Thereafter, everything went awry. 
>>
>
> You must have some custom code in your init.el or are using something
> like use-package as package.el doesn't try to install or upgrade
> packages during init by default.
>
> Where people can come undone is when they are using use-package and set
> the :ensure t option. In this case, use-package will not know about the
> bundled version and will attempt to install org from ELPA. If use
> package runs after org has already been loaded (possibly because some
> other package has been loaded which depends on/requires org mode and has
> loaded the bundled version) then things will break because you will end
> up with a mixed version install. This is why I always ensure org is the very
> first use-package in my init.el and it comes before any other code which
> loads or initialises anything.  
>
>>> The first approach is actually the easiest. The second is hard to get
>>> right and very fragile because packages like use-package and more
>>> specifically, other packages with leverage off org functionality, make it
>>> impossible to reliably know exactly when org is loaded.
>>
>> Using ':after" in use-package is supposed to help that, but I'm not sure
>> it is reliable.  Packages are often incomplete about what other packages
>> it depends on.
>>
>
> You cannot rely on 

Re: Multiple versions of Org in load-path problem

[Tim Cross]

David Masterson  writes:

> Tim Cross  writes:
>
>> David Masterson  writes:
>>
>>> "Michel Schinz"  writes:
>>>
 Just for the record, I also ran into problems when installing Org 9.6
 using Emacs' package system on top of an older version that came with
 Emacs. If I tried to install it as usual (M-x list-packages, then
 install the package from there), I had errors during compilation related
 to `org-assert-version`, and then if I restarted Emacs, I would get a
 fatal error in an unrelated package.

 I managed to solve that problem by:
 1. uninstalling Org 9.6 and exiting Emacs,
 2. starting Emacs with -q,
 3. installing Org 9.6 from there (using M-x list-packages as usual),
 4. restarting Emacs.
>>>
>>> Interesting!  I tried this (essentially) and it worked for my case.  In
>>> my case, I had a built-in Org-9.3 and I was trying to use list-packages
>>> to install Org-9.6. I checked that using -q still added Org-9.3 to
>>> the
>>> load-path, but, since Org wasn't loaded, the install via list-packages
>>> worked.
>>>
>>> The question is what's the proper way of doing this without '-q'?
>
> [...]
>
>> I don't think there is any safe way to install an updated version of
>> org-mode other than
>>
>> 1. Use the -q approach outlined above
>
> Thinking about it, this only works if Org is in elpa as melpa (etc.) are
> not added to package-archives.  You'd have to do some handwritten elisp
> out of *scratch* to setup package-archives if Org-9.6 was still coming
> out of melpa. That's why this can only be labeled as a hack and not a
> solution.
>

Well, yes, if your going to use this technique to load a package which
is not in the default package archives you would need to add that
archive first. People who use this technique often just have a
'update.el' file which they load/evaluate when starting Emacs with -q. 


>> 2. Craft your init.el file such that org functionality is only loaded
>> when explicitly requested and always update as the first action after
>> starting emacs.
>
> In this case, something happened in package-install when trying to
> install Org-9.6 with a built-in Org-9.3.  During the compilation check
> (.el -> .elc) many files failed because the new 'org-assert-version'
> macro was not defined.  Sort of like, after package-install started
> working on Org-9.6, org-macs.el (where org-assert-version should be) got
> loaded *before* the new load-path had been set causing it to load the
> old one from 9.3.  Thereafter, everything went awry. 
>

You must have some custom code in your init.el or are using something
like use-package as package.el doesn't try to install or upgrade
packages during init by default.

Where people can come undone is when they are using use-package and set
the :ensure t option. In this case, use-package will not know about the
bundled version and will attempt to install org from ELPA. If use
package runs after org has already been loaded (possibly because some
other package has been loaded which depends on/requires org mode and has
loaded the bundled version) then things will break because you will end
up with a mixed version install. This is why I always ensure org is the very
first use-package in my init.el and it comes before any other code which
loads or initialises anything.  

>> The first approach is actually the easiest. The second is hard to get
>> right and very fragile because packages like use-package and more
>> specifically, other packages with leverage off org functionality, make it
>> impossible to reliably know exactly when org is loaded.
>
> Using ':after" in use-package is supposed to help that, but I'm not sure
> it is reliable.  Packages are often incomplete about what other packages
> it depends on.
>

You cannot rely on :after. The problem is, other packages may require
org functionality and will load org when they are loaded. This can be
very subtle as there are a lot of packages which only make very small
use of org mode, but even that requires that org mode is loaded. 

>> An approach used by many 'canned' distributions is to postpone package
>> updates. You have a function you run to check for updates which
>> generates a list of packages to update and writes that list to a
>> file. Each time emacs is started, it looks for this update list and if
>> it finds it, it installs packages updates at the very beginning of the
>> init process (before any of your other init.el code or custom
>> blocks). The process also looks for org in the list of packages to
>> update and if it is found, updates it first. 
>
> Probably doesn't work in this case as you would need to be able to use
> package.el suggesting that the load-path has been updated for all
> built-ins already.  The thing I note is that the load-path has already
> been updated for built-ins at the beginning of
> '~/.emacs.d/early-init.el', but the libraries haven't been loaded yet
> (unless needed). That's okay if the newer version of a package then

Re: Multiple versions of Org in load-path problem

[David Masterson]

Tim Cross  writes:

> David Masterson  writes:
>
>> "Michel Schinz"  writes:
>>
>>> Just for the record, I also ran into problems when installing Org 9.6
>>> using Emacs' package system on top of an older version that came with
>>> Emacs. If I tried to install it as usual (M-x list-packages, then
>>> install the package from there), I had errors during compilation related
>>> to `org-assert-version`, and then if I restarted Emacs, I would get a
>>> fatal error in an unrelated package.
>>>
>>> I managed to solve that problem by:
>>> 1. uninstalling Org 9.6 and exiting Emacs,
>>> 2. starting Emacs with -q,
>>> 3. installing Org 9.6 from there (using M-x list-packages as usual),
>>> 4. restarting Emacs.
>>
>> Interesting!  I tried this (essentially) and it worked for my case.  In
>> my case, I had a built-in Org-9.3 and I was trying to use list-packages
>> to install Org-9.6. I checked that using -q still added Org-9.3 to
>> the
>> load-path, but, since Org wasn't loaded, the install via list-packages
>> worked.
>>
>> The question is what's the proper way of doing this without '-q'?

[...]

> I don't think there is any safe way to install an updated version of
> org-mode other than
>
> 1. Use the -q approach outlined above

Thinking about it, this only works if Org is in elpa as melpa (etc.) are
not added to package-archives.  You'd have to do some handwritten elisp
out of *scratch* to setup package-archives if Org-9.6 was still coming
out of melpa. That's why this can only be labeled as a hack and not a
solution.

> 2. Craft your init.el file such that org functionality is only loaded
> when explicitly requested and always update as the first action after
> starting emacs.

In this case, something happened in package-install when trying to
install Org-9.6 with a built-in Org-9.3.  During the compilation check
(.el -> .elc) many files failed because the new 'org-assert-version'
macro was not defined.  Sort of like, after package-install started
working on Org-9.6, org-macs.el (where org-assert-version should be) got
loaded *before* the new load-path had been set causing it to load the
old one from 9.3.  Thereafter, everything went awry. 

> The first approach is actually the easiest. The second is hard to get
> right and very fragile because packages like use-package and more
> specifically, other packages with leverage off org functionality, make it
> impossible to reliably know exactly when org is loaded.

Using ':after" in use-package is supposed to help that, but I'm not sure
it is reliable.  Packages are often incomplete about what other packages
it depends on.

> An approach used by many 'canned' distributions is to postpone package
> updates. You have a function you run to check for updates which
> generates a list of packages to update and writes that list to a
> file. Each time emacs is started, it looks for this update list and if
> it finds it, it installs packages updates at the very beginning of the
> init process (before any of your other init.el code or custom
> blocks). The process also looks for org in the list of packages to
> update and if it is found, updates it first. 

Probably doesn't work in this case as you would need to be able to use
package.el suggesting that the load-path has been updated for all
built-ins already.  The thing I note is that the load-path has already
been updated for built-ins at the beginning of
'~/.emacs.d/early-init.el', but the libraries haven't been loaded yet
(unless needed). That's okay if the newer version of a package then
cleanly replaces all the files in the old version.

> I don't think there is a safe way to load org mode after the init
> process i.e. after booting emacs by M-x package-update.

Where is package-update called in the boot process of emacs?  I don't
see package-update in Emacs v2.7.

> I've had good success using straight.el. I had to be careful regarding
> how I structured my init.el file (ensuring any straight stuff happens
> first and the first use package stanza is for org. The main reason
> straight works well for me is that my work flow is to do a M-x
> straight-pull-all when I want to update my packages. This does a git
> pull for all the sources, but does not do any build/install. This occurs
> when I next start Emacs and because I have all the straight stuff at the
> start and because org mode is the first straight-use-package, the update
> and install happens before any other org functionality is loaded,
> avoiding mixed version issues.

Where do you get straight.el?  I don't see it in [m]elpa.

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[Tim Cross]

David Masterson  writes:

> Adding this to bug #59882
>
> "Michel Schinz"  writes:
>
>> Just for the record, I also ran into problems when installing Org 9.6
>> using Emacs' package system on top of an older version that came with
>> Emacs. If I tried to install it as usual (M-x list-packages, then
>> install the package from there), I had errors during compilation related
>> to `org-assert-version`, and then if I restarted Emacs, I would get a
>> fatal error in an unrelated package.
>>
>> I managed to solve that problem by:
>> 1. uninstalling Org 9.6 and exiting Emacs,
>> 2. starting Emacs with -q,
>> 3. installing Org 9.6 from there (using M-x list-packages as usual),
>> 4. restarting Emacs.
>
> Interesting!  I tried this (essentially) and it worked for my case.  In
> my case, I had a built-in Org-9.3 and I was trying to use list-packages
> to install Org-9.6. I checked that using -q still added Org-9.3 to the
> load-path, but, since Org wasn't loaded, the install via list-packages
> worked.
>
> The question is what's the proper way of doing this without '-q'?
>
>> I'm not sure this is related to your problem, or whether that helps (but
>> I hope it does)...
>
> I think it does.
>
> Side note:
>
> In my testing, I found a strange case where, in *scratch*, I get:
>
> (message "%s" org-version)
> ;; Error undefined
> ;; Do 'C-h v org-version'
> (message "%s" org-version)
> 9.3
>
> So, 'describe-variable' on org-version causes Org to be loaded?!?  Why
> do I have a feeling this is related to this bug?

I don't think there is any safe way to install an updated version of
org-mode other than

1. Use the -q approach outlined above

2. Craft your init.el file such that org functionality is only loaded
when explicitly requested and always update as the first action after
starting emacs.

The first approach is actually the easiest. The second is hard to get
right and very fragile because packages like use-package and more
specifically, other packages with leverage off org functionality, make it
impossible to reliably know exactly when org is loaded.

An approach used by many 'canned' distributions is to postpone package
updates. You have a function you run to check for updates which
generates a list of packages to update and writes that list to a
file. Each time emacs is started, it looks for this update list and if
it finds it, it installs packages updates at the very beginning of the
init process (before any of your other init.el code or custom
blocks). The process also looks for org in the list of packages to
update and if it is found, updates it first. 

I don't think there is a safe way to load org mode after the init
process i.e. after booting emacs by M-x package-update.

I've had good success using straight.el. I had to be careful regarding
how I structured my init.el file (ensuring any straight stuff happens
first and the first use package stanza is for org. The main reason
straight works well for me is that my work flow is to do a M-x
straight-pull-all when I want to update my packages. This does a git
pull for all the sources, but does not do any build/install. This occurs
when I next start Emacs and because I have all the straight stuff at the
start and because org mode is the first straight-use-package, the update
and install happens before any other org functionality is loaded,
avoiding mixed version issues.

Re: Multiple versions of Org in load-path problem

[David Masterson]

Adding this to bug #59882

"Michel Schinz"  writes:

> Just for the record, I also ran into problems when installing Org 9.6
> using Emacs' package system on top of an older version that came with
> Emacs. If I tried to install it as usual (M-x list-packages, then
> install the package from there), I had errors during compilation related
> to `org-assert-version`, and then if I restarted Emacs, I would get a
> fatal error in an unrelated package.
>
> I managed to solve that problem by:
> 1. uninstalling Org 9.6 and exiting Emacs,
> 2. starting Emacs with -q,
> 3. installing Org 9.6 from there (using M-x list-packages as usual),
> 4. restarting Emacs.

Interesting!  I tried this (essentially) and it worked for my case.  In
my case, I had a built-in Org-9.3 and I was trying to use list-packages
to install Org-9.6. I checked that using -q still added Org-9.3 to the
load-path, but, since Org wasn't loaded, the install via list-packages
worked.

The question is what's the proper way of doing this without '-q'?

> I'm not sure this is related to your problem, or whether that helps (but
> I hope it does)...

I think it does.

Side note:

In my testing, I found a strange case where, in *scratch*, I get:

(message "%s" org-version)
;; Error undefined
;; Do 'C-h v org-version'
(message "%s" org-version)
9.3

So, 'describe-variable' on org-version causes Org to be loaded?!?  Why
do I have a feeling this is related to this bug?

-- 
David Masterson

RE: Multiple versions of Org in load-path problem

[Cook, Malcolm]

>Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> I went so far as to add the following to early-init.el:
>>>
>>> (if (featurep 'org) (unload-feature 'org))
>>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>>> (load-library "org")
>>>
>>> The load-library still fails with the org-assert-version error.
>>
>> Indeed. It is to be expected. M-x package-install should not err here
>> though. In theory.
>
>My testing says that, in early-init.el, Org is not yet a feature, so the
>built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
>path for Org-9.6 should put it at the front of the load-path and
>(hopefully) override Org-9.3 if it is in the load-path (I think I
>checked that). The error in the load-library is, therefore, a problem
>with Org-9.6 installed by package-install. 
>
>> I suggest you to read `org-assert-version'. It aims to catch the
>> situation above and similar.
>
>This is chicken and egg problem. I can't use 'org-assert-version'
>unless I can get Org to load.
>
>> Note, however, that installation problem is different. Or rather it
>> should be different.
>>
>>> Could it be that, when you package-install Org-9.6, it runs through a
>>> check where (I think) it compiles the package? I get a lot of warnings
>>> and 34(?) failed files. Could it be that some of the files are not
>>> built and, so, when I load-library, I'm picking up some of the wrong
>>> files from the built-in Org-9.3? Do we need to remove all versions of
>>> Org that is not the current version from the load-path at the very
>>> beginning of org.el to ensure no fall-through? Kind of a hack, but...

Hi,

I've been reading along as I've been similarly hounded in years past with org 
version changes.

It really sounds like you compiled org-9.6 with Org-9.3 already loaded.

I'd recommend reinstalling.

Here is one way to do it that is pretty safe:

> emacs -Q -batch -eval "(progn (require 'package) (package-initialize) 
 (package-refresh-contents) (package-install 'org))"

If after doing this, and running emacs, you find M-x org-version does not 
return 9.6, or you find the package assert problem, I'd try the more paranoid:
> emacs -Q -batch -eval "(progn (require 'cl-seq) (delete (car 
(cl-member "lisp/org" load-path :test  #'string-match)) load-path) (require 
'package) (package-initialize)  (package-refresh-contents) (package-install 
'org))"

And possibly consider adding to your init.el at the very top:

(require 'cl-seq) (delete (car (cl-member "lisp/org" load-path :test  
#'string-match)) load-path)

YMMV,

~ Malcolm

>>
>> Maybe. It should not. That's why I raised
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>> I'd like to see if Emacs devs have anything to say here.
>
>Good. I'm not used to bug reporting in Emacs, so I raised a question on
>use-package in mailto:emacs-de...@gnu.org, but they pointed me at your bug.
>I'll see if I can add anything there.
>
>-- 
>David Masterson
>

Re: Multiple versions of Org in load-path problem

[Michel Schinz]

Just for the record, I also ran into problems when installing Org 9.6
using Emacs' package system on top of an older version that came with
Emacs. If I tried to install it as usual (M-x list-packages, then
install the package from there), I had errors during compilation related
to `org-assert-version`, and then if I restarted Emacs, I would get a
fatal error in an unrelated package.

I managed to solve that problem by:
1. uninstalling Org 9.6 and exiting Emacs,
2. starting Emacs with -q,
3. installing Org 9.6 from there (using M-x list-packages as usual),
4. restarting Emacs.

I'm not sure this is related to your problem, or whether that helps (but
I hope it does)...

Michel.

On Thu, 8 Dec 2022, at 19:24, David Masterson wrote:
> Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> I went so far as to add the following to early-init.el:
>>>
>>> (if (featurep 'org) (unload-feature 'org))
>>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>>> (load-library "org")
>>>
>>> The load-library still fails with the org-assert-version error.
>>
>> Indeed. It is to be expected. M-x package-install should not err here
>> though. In theory.
>
> My testing says that, in early-init.el, Org is not yet a feature, so the
> built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
> path for Org-9.6 should put it at the front of the load-path and
> (hopefully) override Org-9.3 if it is in the load-path (I think I
> checked that).  The error in the load-library is, therefore, a problem
> with Org-9.6 installed by package-install. 
>
>> I suggest you to read `org-assert-version'. It aims to catch the
>> situation above and similar.
>
> This is chicken and egg problem.  I can't use 'org-assert-version'
> unless I can get Org to load.
>
>> Note, however, that installation problem is different. Or rather it
>> should be different.
>>
>>> Could it be that, when you package-install Org-9.6, it runs through a
>>> check where (I think) it compiles the package?  I get a lot of warnings
>>> and 34(?) failed files.  Could it be that some of the files are not
>>> built and, so, when I load-library, I'm picking up some of the wrong
>>> files from the built-in Org-9.3?  Do we need to remove all versions of
>>> Org that is not the current version from the load-path at the very
>>> beginning of org.el to ensure no fall-through?  Kind of a hack, but...
>>
>> Maybe. It should not. That's why I raised
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>> I'd like to see if Emacs devs have anything to say here.
>
> Good. I'm not used to bug reporting in Emacs, so I raised a question on
> use-package in emacs-de...@gnu.org, but they pointed me at your bug.
> I'll see if I can add anything there.
>
> -- 
> David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> I went so far as to add the following to early-init.el:
>>
>> (if (featurep 'org) (unload-feature 'org))
>> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
>> (load-library "org")
>>
>> The load-library still fails with the org-assert-version error.
>
> Indeed. It is to be expected. M-x package-install should not err here
> though. In theory.

My testing says that, in early-init.el, Org is not yet a feature, so the
built-in Org-9.3 is not yet loaded and the first 'if' fails. Adding the
path for Org-9.6 should put it at the front of the load-path and
(hopefully) override Org-9.3 if it is in the load-path (I think I
checked that).  The error in the load-library is, therefore, a problem
with Org-9.6 installed by package-install. 

> I suggest you to read `org-assert-version'. It aims to catch the
> situation above and similar.

This is chicken and egg problem.  I can't use 'org-assert-version'
unless I can get Org to load.

> Note, however, that installation problem is different. Or rather it
> should be different.
>
>> Could it be that, when you package-install Org-9.6, it runs through a
>> check where (I think) it compiles the package?  I get a lot of warnings
>> and 34(?) failed files.  Could it be that some of the files are not
>> built and, so, when I load-library, I'm picking up some of the wrong
>> files from the built-in Org-9.3?  Do we need to remove all versions of
>> Org that is not the current version from the load-path at the very
>> beginning of org.el to ensure no fall-through?  Kind of a hack, but...
>
> Maybe. It should not. That's why I raised
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
> I'd like to see if Emacs devs have anything to say here.

Good. I'm not used to bug reporting in Emacs, so I raised a question on
use-package in emacs-de...@gnu.org, but they pointed me at your bug.
I'll see if I can add anything there.

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> I have to play with the solution I suggested.  I'm beginning to wonder
> if it will cause other problems with (seeming) Org dependent packages.
> In my case, the error I get is from various use-package calls --
> something like "Error: org-assert-version is not known".  This is
> confusing because I've arranged my .emacs as (almost) an alphabetical
> loading of the packages and some of the use-package errors are coming
> from packages loaded before Org.  IOW, org-assert-version from 9.6
> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
> what's referring to org-assert-version?

If you install Org via package-install (or :ensure t), Org 9.6 should
get loaded once package system is initialized. Emacs should correctly
put ELPA's version of Org in from of the load-path. However, it looks
like Org 9.6 compilation is off and `org-assert-version' macro is
compiled as a function call instead of a macro.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> I went so far as to add the following to early-init.el:
>
> (if (featurep 'org) (load-feature 'org))
> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
> (load-library "org")
>
> The load-library still fails with the org-assert-version error.

Indeed. It is to be expected. M-x package-install should not err here
though. In theory.

I suggest you to read `org-assert-version'. It aims to catch the
situation above and similar.

Note, however, that installation problem is different. Or rather it
should be different.

> Could it be that, when you package-install Org-9.6, it runs through a
> check where (I think) it compiles the package?  I get a lot of warnings
> and 34(?) failed files.  Could it be that some of the files are not
> built and, so, when I load-library, I'm picking up some of the wrong
> files from the built-in Org-9.3?  Do we need to remove all versions of
> Org that is not the current version from the load-path at the very
> beginning of org.el to ensure no fall-through?  Kind of a hack, but...

Maybe. It should not. That's why I raised
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
I'd like to see if Emacs devs have anything to say here.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Multiple versions of Org in load-path problem

[David Masterson]

David Masterson  writes:

> David Masterson  writes:
>
>> Ihor Radchenko  writes:
>>
>>> David Masterson  writes:
>>>
 Is there a proper way to do this?  Do I really have to delete the
 built-in 9.3 version (by hand or package-delete?) or will that mess up
 something else?  I saw mention of 'unload-feature' which is new to me --
 would that be safe to use?
>>>
>>> In theory, Emacs should handle such updates even when built-in Org is
>>> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>>
>> I'm going to test if (in my case) the buit-in 9.3 is already loaded when
>> my .emacs runs,  I also have to see when 9.6 loads in my .emacs.
>>
>>> unload-feature is the last resort. We are still discussing the available
>>> options in https://orgmode.org/list/87k033h218.fsf@localhost.
>>
>> I have to play with the solution I suggested.  I'm beginning to wonder
>> if it will cause other problems with (seeming) Org dependent packages.
>> In my case, the error I get is from various use-package calls --
>> something like "Error: org-assert-version is not known".  This is
>> confusing because I've arranged my .emacs as (almost) an alphabetical
>> loading of the packages and some of the use-package errors are coming
>> from packages loaded before Org.  IOW, org-assert-version from 9.6
>> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
>> what's referring to org-assert-version?
>
> I went so far as to add the following to early-init.el:
>
> (if (featurep 'org) (load-feature 'org))

typo -- unload-feature

> (add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
> (load-library "org")
>
> The load-library still fails with the org-assert-version error.
>
> Could it be that, when you package-install Org-9.6, it runs through a
> check where (I think) it compiles the package?  I get a lot of warnings
> and 34(?) failed files.  Could it be that some of the files are not
> built and, so, when I load-library, I'm picking up some of the wrong
> files from the built-in Org-9.3?  Do we need to remove all versions of
> Org that is not the current version from the load-path at the very
> beginning of org.el to ensure no fall-through?  Kind of a hack, but...

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

David Masterson  writes:

> Ihor Radchenko  writes:
>
>> David Masterson  writes:
>>
>>> Is there a proper way to do this?  Do I really have to delete the
>>> built-in 9.3 version (by hand or package-delete?) or will that mess up
>>> something else?  I saw mention of 'unload-feature' which is new to me --
>>> would that be safe to use?
>>
>> In theory, Emacs should handle such updates even when built-in Org is
>> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882
>
> I'm going to test if (in my case) the buit-in 9.3 is already loaded when
> my .emacs runs,  I also have to see when 9.6 loads in my .emacs.
>
>> unload-feature is the last resort. We are still discussing the available
>> options in https://orgmode.org/list/87k033h218.fsf@localhost.
>
> I have to play with the solution I suggested.  I'm beginning to wonder
> if it will cause other problems with (seeming) Org dependent packages.
> In my case, the error I get is from various use-package calls --
> something like "Error: org-assert-version is not known".  This is
> confusing because I've arranged my .emacs as (almost) an alphabetical
> loading of the packages and some of the use-package errors are coming
> from packages loaded before Org.  IOW, org-assert-version from 9.6
> shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
> what's referring to org-assert-version?

I went so far as to add the following to early-init.el:

(if (featurep 'org) (load-feature 'org))
(add-to-list 'load-path (expand-file-name "~/.emacs.d/elpa/org-9.6")
(load-library "org")

The load-library still fails with the org-assert-version error.

Could it be that, when you package-install Org-9.6, it runs through a
check where (I think) it compiles the package?  I get a lot of warnings
and 34(?) failed files.  Could it be that some of the files are not
built and, so, when I load-library, I'm picking up some of the wrong
files from the built-in Org-9.3?  Do we need to remove all versions of
Org that is not the current version from the load-path at the very
beginning of org.el to ensure no fall-through?  Kind of a hack, but...

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[David Masterson]

Ihor Radchenko  writes:

> David Masterson  writes:
>
>> Is there a proper way to do this?  Do I really have to delete the
>> built-in 9.3 version (by hand or package-delete?) or will that mess up
>> something else?  I saw mention of 'unload-feature' which is new to me --
>> would that be safe to use?
>
> In theory, Emacs should handle such updates even when built-in Org is
> loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882

I'm going to test if (in my case) the buit-in 9.3 is already loaded when
my .emacs runs,  I also have to see when 9.6 loads in my .emacs.

> unload-feature is the last resort. We are still discussing the available
> options in https://orgmode.org/list/87k033h218.fsf@localhost.

I have to play with the solution I suggested.  I'm beginning to wonder
if it will cause other problems with (seeming) Org dependent packages.
In my case, the error I get is from various use-package calls --
something like "Error: org-assert-version is not known".  This is
confusing because I've arranged my .emacs as (almost) an alphabetical
loading of the packages and some of the use-package errors are coming
from packages loaded before Org.  IOW, org-assert-version from 9.6
shouldn't be loaded yet and 9.3 doesn't have org-assert-version. So
what's referring to org-assert-version?

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[Ihor Radchenko]

David Masterson  writes:

> Is there a proper way to do this?  Do I really have to delete the
> built-in 9.3 version (by hand or package-delete?) or will that mess up
> something else?  I saw mention of 'unload-feature' which is new to me --
> would that be safe to use?

In theory, Emacs should handle such updates even when built-in Org is
loaded. See https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59882

unload-feature is the last resort. We are still discussing the available
options in https://orgmode.org/list/87k033h218.fsf@localhost.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Multiple versions of Org in load-path problem

[David Masterson]

 writes:

> On Mon, Dec 05, 2022 at 06:50:33PM -0800, David Masterson wrote:
>> I'm using Debian v11.5 on my Chromebook.  I have used 'apt install' to
>> load the pre-built version of Emacs 27.1.  I've just found out that it
>> installs a pre-built version of Org-9.3 in /usr/share/emacs/27.1/lisp.
>> That directory is early in the load-path, so it appears to be loaded out
>> of startup.el(?).  Everything seems to be working fine in my setup of
>> Emacs and Org.
>
> Hm. I run a self-compiled Emacs, so I can't check at the moment;
> take this with a grain of salt.
>
> That said for a distro putting the distro-provided places earlier
> in the load-path than the local- or user-provided ones seems wrong;
> admins/users have no chance to override them, no?

Hmm.  You could be correct.  Which means it's the order of loading in my
.emacs file.  I'll have to test this to see when Org is first loaded.

-- 
David Masterson

Re: Multiple versions of Org in load-path problem

[tomas]

On Mon, Dec 05, 2022 at 06:50:33PM -0800, David Masterson wrote:
> I'm using Debian v11.5 on my Chromebook.  I have used 'apt install' to
> load the pre-built version of Emacs 27.1.  I've just found out that it
> installs a pre-built version of Org-9.3 in /usr/share/emacs/27.1/lisp.
> That directory is early in the load-path, so it appears to be loaded out
> of startup.el(?).  Everything seems to be working fine in my setup of
> Emacs and Org.

Hm. I run a self-compiled Emacs, so I can't check at the moment;
take this with a grain of salt.

That said for a distro putting the distro-provided places earlier
in the load-path than the local- or user-provided ones seems wrong;
admins/users have no chance to override them, no?

Cheers
-- 
t


signature.asc
Description: PGP signature