org 9.2.6 and org 9.1.9

org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

org 9.1.9 is a built-in

but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.

Why does that happen ?

Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues with that situation and that's extremely confusing. What is the best way to solve that ?



Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: org 9.2.6 and org 9.1.9

[Nick Dokos]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> writes:

> org 9.1.9 is a built-in
>
> but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.
>

What conflicts are you seeing? I have the built-in 9.1.9 org that
comes with emacs but I run (close to) latest master and I see no
problems: the only thing I do is to set my load-path to point to the
right place (and make sure that that setting precedes the
/usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):

    (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))

Although that has been enough for me, it's probably safer to delete
from load-path all other org entries, thereby making the built-in
version invisible to emacs - in my case, I just have the one:

   (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)

That way, if you happen to do something like `(require 'old-org-req)'
with a requirement that is not satisfied by current org, but is
satisfied by the built-in org, you'd get an error, rather than getting
a mixed installation.

> Why does that happen ?
>
> Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> with that situation and that's extremely confusing. What is the best
> way to solve that ?
>

I think the above should be enough (and IME it is), but maybe someone can
think of other things that might trip one up.

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 3698 bytes --]

There is a very important rule which must be followed wrt org-mode
installation. It is critical that no version of org is already loaded
before installing a new version. This can be quite tricky as many of us
have org setups which automatically load some org functionality without
explicitly opening an org file or agenda view (for example, you might be
using an org add-on for email). Situation is worse if we are loading org as
part of our init.el.

I'm also not sure that tweaking the load-path order is sufficient if your
installing org via M-x package-install as there is a 'chicken and egg'
problem with the initial install. If your init.el file is loading org
functionality and you only have the built-in org version installed, that
version will be loaded before you run package-install. Probably works if
you install via your init.el though.

I've found the safest thing to do is only use autoload or use-package with
deferred loading for org and whenever updating org (I use the
org-plus-contrib package from the org elpa repo) only update immediately
after a fresh restart of emacs and before doing anything else.  Failing to
do this often results in a broken build as you get a set of new org elc
files which contains definitions from two different org versions. When the
versions are only different in minor version numbers, this mixed build may
not even be noticeable, but when major version differences exist, you get
the symptom of broken functionality, missing definitions or unbound symbols.

The situation is made worse by package maintainers specifying the latest
org version rather than the version built into Emacs when the bundled
version would be sufficient.

It took me a while to structure my init.el file such that no org
functionality was loaded until I used something which depends on it.
However, once I did, provided I only update org in a fresh new session, all
works flawlessly. I found use-package package really helped with this.



On Wed, 27 Nov 2019 at 06:22, Nick Dokos <ndokos@gmail.com> wrote:

> Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>
> writes:
>
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both
> installed creates conflicts.
> >
>
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
>
>     (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
>
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
>
>    (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
>
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
>
> > Why does that happen ?
> >
> > Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> > with that situation and that's extremely confusing. What is the best
> > way to solve that ?
> >
>
> I think the above should be enough (and IME it is), but maybe someone can
> think of other things that might trip one up.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 4628 bytes --]

RE: org 9.2.6 and org 9.1.9

[Cook, Malcolm]

[-- Attachment #1: Type: text/plain, Size: 5058 bytes --]

Tim,



Yes, it is a bit of dependency hell.



Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x<https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2016-08/msg00138.html> :





Here's what I do, at the shell:



          emacs -Q -batch -eval "(progn (require 'package) (add-to-list

'package-archives '(\"org\" . \"http://orgmode.org/elpa/\"<http://orgmode.org/elpa/%22>;))

(package-initialize) (package-refresh-contents) (package-install

'org-plus-contrib))"



This assures that org is not already loaded when org is compiled, which I've

learned is the source of creating a mess.



Note: I use org-plus-contrib from melpa instead of org.  If you want just org,

you could simply:



          emacs -Q -batch -eval "(progn (require 'package) (package-initialize)

(package-refresh-contents) (package-install 'org-plus-contrib))"



HTH,



Malcolm



From: Emacs-orgmode <emacs-orgmode-bounces+mec=stowers.org@gnu.org> On Behalf Of Tim Cross
Sent: Tuesday, November 26, 2019 3:41 PM
To: Nick Dokos <ndokos@gmail.com>
Cc: Org-mode <emacs-orgmode@gnu.org>; Emacs developers <emacs-devel@gnu.org>
Subject: Re: org 9.2.6 and org 9.1.9

CAUTION: This email was received from an External Source

There is a very important rule which must be followed wrt org-mode installation. It is critical that no version of org is already loaded before installing a new version. This can be quite tricky as many of us have org setups which automatically load some org functionality without explicitly opening an org file or agenda view (for example, you might be using an org add-on for email). Situation is worse if we are loading org as part of our init.el.

I'm also not sure that tweaking the load-path order is sufficient if your installing org via M-x package-install as there is a 'chicken and egg' problem with the initial install. If your init.el file is loading org functionality and you only have the built-in org version installed, that version will be loaded before you run package-install. Probably works if you install via your init.el though.

I've found the safest thing to do is only use autoload or use-package with deferred loading for org and whenever updating org (I use the org-plus-contrib package from the org elpa repo) only update immediately after a fresh restart of emacs and before doing anything else.  Failing to do this often results in a broken build as you get a set of new org elc files which contains definitions from two different org versions. When the versions are only different in minor version numbers, this mixed build may not even be noticeable, but when major version differences exist, you get the symptom of broken functionality, missing definitions or unbound symbols.

The situation is made worse by package maintainers specifying the latest org version rather than the version built into Emacs when the bundled version would be sufficient.

It took me a while to structure my init.el file such that no org functionality was loaded until I used something which depends on it. However, once I did, provided I only update org in a fresh new session, all works flawlessly. I found use-package package really helped with this.



On Wed, 27 Nov 2019 at 06:22, Nick Dokos <ndokos@gmail.com<mailto:ndokos@gmail.com>> wrote:
Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org<mailto:jean.christophe.helary@traduction-libre.org>> writes:

> org 9.1.9 is a built-in
>
> but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.
>

What conflicts are you seeing? I have the built-in 9.1.9 org that
comes with emacs but I run (close to) latest master and I see no
problems: the only thing I do is to set my load-path to point to the
right place (and make sure that that setting precedes the
/usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):

    (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))

Although that has been enough for me, it's probably safer to delete
from load-path all other org entries, thereby making the built-in
version invisible to emacs - in my case, I just have the one:

   (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)

That way, if you happen to do something like `(require 'old-org-req)'
with a requirement that is not satisfied by current org, but is
satisfied by the built-in org, you'd get an error, rather than getting
a mixed installation.

> Why does that happen ?
>
> Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> with that situation and that's extremely confusing. What is the best
> way to solve that ?
>

I think the above should be enough (and IME it is), but maybe someone can
think of other things that might trip one up.

--
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler



--
regards,

Tim

--
Tim Cross


[-- Attachment #2: Type: text/html, Size: 11912 bytes --]

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

> On Nov 27, 2019, at 11:59, Cook, Malcolm <MEC@stowers.org> wrote:
> 
> Tim,
>  
> Yes, it is a bit of dependency hell.

I see 2 solutions here:

1) org is only provided as a built-in package and updated there when necessary
2) org is removed from the built in packages

The current situation is really weird.

Jean-Christophe

>  
> Quoting myself from Re: [O] How to safely update from ver. 8.2.10 to 8.3.x :
>  
>  
> Here's what I do, at the shell:
>  
>           emacs -Q -batch -eval "(progn (require 'package) (add-to-list 
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\";))  
> (package-initialize) (package-refresh-contents) (package-install 
> 'org-plus-contrib))"
>  
> This assures that org is not already loaded when org is compiled, which I've 
> learned is the source of creating a mess.
>  
> Note: I use org-plus-contrib from melpa instead of org.  If you want just org, 
> you could simply:
>  
>           emacs -Q -batch -eval "(progn (require 'package) (package-initialize) 
> (package-refresh-contents) (package-install 'org-plus-contrib))"
>  
> HTH,
>  
> Malcolm
>  
>  
>  
> From: Emacs-orgmode <emacs-orgmode-bounces+mec=stowers.org@gnu.org> On Behalf Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos <ndokos@gmail.com>
> Cc: Org-mode <emacs-orgmode@gnu.org>; Emacs developers <emacs-devel@gnu.org>
> Subject: Re: org 9.2.6 and org 9.1.9
>  
> CAUTION: This email was received from an External Source
>  
> 
> There is a very important rule which must be followed wrt org-mode installation. It is critical that no version of org is already loaded before installing a new version. This can be quite tricky as many of us have org setups which automatically load some org functionality without explicitly opening an org file or agenda view (for example, you might be using an org add-on for email). Situation is worse if we are loading org as part of our init.el.
>  
> I'm also not sure that tweaking the load-path order is sufficient if your installing org via M-x package-install as there is a 'chicken and egg' problem with the initial install. If your init.el file is loading org functionality and you only have the built-in org version installed, that version will be loaded before you run package-install. Probably works if you install via your init.el though.
>  
> I've found the safest thing to do is only use autoload or use-package with deferred loading for org and whenever updating org (I use the org-plus-contrib package from the org elpa repo) only update immediately after a fresh restart of emacs and before doing anything else.  Failing to do this often results in a broken build as you get a set of new org elc files which contains definitions from two different org versions. When the versions are only different in minor version numbers, this mixed build may not even be noticeable, but when major version differences exist, you get the symptom of broken functionality, missing definitions or unbound symbols.
>  
> The situation is made worse by package maintainers specifying the latest org version rather than the version built into Emacs when the bundled version would be sufficient.
>  
> It took me a while to structure my init.el file such that no org functionality was loaded until I used something which depends on it. However, once I did, provided I only update org in a fresh new session, all works flawlessly. I found use-package package really helped with this. 
>  
>  
>  
> On Wed, 27 Nov 2019 at 06:22, Nick Dokos <ndokos@gmail.com> wrote:
> Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> writes:
> 
> > org 9.1.9 is a built-in
> >
> > but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.
> >
> 
> What conflicts are you seeing? I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems: the only thing I do is to set my load-path to point to the
> right place (and make sure that that setting precedes the
> /usr/local/share/emacs/27.0.50/lisp/org setting that emacs adds):
> 
>     (add-to-list 'load-path (expand-file-name "~/elisp/org-mode/lisp"))
> 
> Although that has been enough for me, it's probably safer to delete
> from load-path all other org entries, thereby making the built-in
> version invisible to emacs - in my case, I just have the one:
> 
>    (delete "/usr/local/share/emacs/27.0.50/lisp/org" load-path)
> 
> That way, if you happen to do something like `(require 'old-org-req)'
> with a requirement that is not satisfied by current org, but is
> satisfied by the built-in org, you'd get an error, rather than getting
> a mixed installation.
> 
> > Why does that happen ?
> >
> > Can't 9.2.6 override 9.1.9 ? It's not the first time I have issues
> > with that situation and that's extremely confusing. What is the best
> > way to solve that ?
> >
> 
> I think the above should be enough (and IME it is), but maybe someone can
> think of other things that might trip one up.
> 
> -- 
> Nick
> 
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
> 
> 
> 
> 
> -- 
> regards,
>  
> Tim
>  
> --
> Tim Cross

Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> writes:

> > Yes, it is a bit of dependency hell.
>
> I see 2 solutions here:
>
> 1) org is only provided as a built-in package and updated there when necessary

Even if we removed it from GNU ELPA, nothing stops unofficial packages
from cropping up when users want to run the latest and greatest.
Users of such packages would then report bugs when things broke, and
we would be back where we started.

(BTW, there already is a separate package archive on https://orgmode.org/elpa/.)

> 2) org is removed from the built in packages

Option 2 would be extremely unfortunate, to put it mildly.  It would
leave a lot of users without functionality they've come to expect and
depend on to be there in the default install.  GNU ELPA is not always
a practical alternative (just to give one example, on servers or
networks not connected to the internet).

And even if we remove org-mode, who is to say that other packages
won't see the same issues in the future?  Should we just accept that
we have to remove any package from Emacs which runs into this?

IMO, let's work on fixing the underlying problems instead.  Elsewhere
in this thread, Stefan Monnier and others has pointed out what needs
to be done: now we need to figure out how to do it.

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Stefan Monnier]

> Here's what I do, at the shell:
>
>
>
>           emacs -Q -batch -eval "(progn (require 'package) (add-to-list
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\"<http://orgmode.org/elpa/%22>;))
> (package-initialize) (package-refresh-contents) (package-install
> 'org-plus-contrib))"

I can't blame you for using such workarounds, but it would *really* help
if you could report the actual problems encountered (and then use the
workaround until we fix the source of the problem).


        Stefan

RE: org 9.2.6 and org 9.1.9

[Cook, Malcolm]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Hi Stefan,



I don’t think I’ve ever seen a root-cause analysis, but I’ve seen many problems that are resolved by some version of a “clean build” of org.  Here are some:



- [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2012-09/msg01365.html][Installing Org through the new http://orgmode.org ELPA]]

- [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00316.html][latest org from Elpa error: Invalid function: org-babel-header-a]]

- [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00318.html][Re: [O] wrong type argument listp... org-element-set-contents]]



That's what I got.



BTW: I now use org-plus-contrib in place of org with this mantra:



(add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/") t)

(use-package  org ;org-plus-contrib                                          ; instead of org-mode

  :ensure org-plus-contrib ; following http://emacs.stackexchange.com/questions/7890/org-plus-contrib-and-org-with-require-or-use-package

)



- Cheers
Malcolm

> Here's what I do, at the shell:
>
>
>
> emacs -Q -batch -eval "(progn (require 'package) (add-to-list
> 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\<http://orgmode.org/elpa/>"<http://orgmode.org/elpa/%22>;))
> (package-initialize) (package-refresh-contents) (package-install
> 'org-plus-contrib))"

I can't blame you for using such workarounds, but it would *really* help
if you could report the actual problems encountered (and then use the
workaround until we fix the source of the problem).


Stefan

[-- Attachment #2: Type: text/html, Size: 5360 bytes --]

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 3206 bytes --]

>> But I don't think the issue is with package.el per se.

> Maybe it needs fixes elsewhere as well, but it's via package.el that the
> problem is usually exposed.

Yes, but I think that is mainly because that is the most common way people
install it. The manual is fairly clear on this - don't install org-mode vai
package.el if you have already visited an org file (or loaded
org-functionality). Package.el does make it worse as it may install org as
a dependency rather than as a result of an explicit request from the user.

>> You get the same problem if you try to install org-mode manually
>> without package.el.

> Depends how you do it.

True. If you build it using 'make' it is in a separate environment, using
batch and avoiding your init.el, so no issues.

It has been mentioned a few times in this thread that issues need to be
reported so that they can be logged as bugs and fixed. Unfortunately, this
is very difficult as the package.el installation does not fail. Everything
appears to have worked fine and even when you then start working with org
afterwards, it can appear to all be fine until you try some action, at
which point you get an error. This may not happen for hours, days or even
in a later session, so the connection between installation and problem is
lost.

On Thu, 28 Nov 2019 at 04:20, Cook, Malcolm <MEC@stowers.org> wrote:

> Hi Stefan,
>
>
>
> I don’t think I’ve ever seen a root-cause analysis, but I’ve seen many
> problems that are resolved by some version of a “clean build” of org.  Here
> are some:
>
>
>
> - [[
> https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2012-09/msg01365.html][Installing
> Org through the new http://orgmode.org ELPA]]
>
> - [[
> https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00316.html][latest
> org from Elpa error: Invalid function: org-babel-header-a]]
>
> - [[
> https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00318.html][Re:
> [O] wrong type argument listp... org-element-set-contents]]
>
>
>
> That's what I got.
>
>
>
> BTW: I now use org-plus-contrib in place of org with this mantra:
>
>
>
> (add-to-list 'package-archives '("org" . "http://orgmode.org/elpa/") t)
>
> (use-package  org
> ;org-plus-contrib                                          ; instead of
> org-mode
>
>   :ensure org-plus-contrib ; following
> http://emacs.stackexchange.com/questions/7890/org-plus-contrib-and-org-with-require-or-use-package
>
> )
>
>
>
> - Cheers
>
> Malcolm
>
>
>
> > Here's what I do, at the shell:
> >
> >
> >
> > emacs -Q -batch -eval "(progn (require 'package) (add-to-list
> > 'package-archives '(\"org\" . \"http://orgmode.org/elpa/\
> <http://orgmode.org/elpa/>"<http://orgmode.org/elpa/%22>;))
> > (package-initialize) (package-refresh-contents) (package-install
> > 'org-plus-contrib))"
>
> I can't blame you for using such workarounds, but it would *really* help
> if you could report the actual problems encountered (and then use the
> workaround until we fix the source of the problem).
>
>
> Stefan
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 6468 bytes --]

Re: org 9.2.6 and org 9.1.9

[Stefan Monnier]

> [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2012-09/msg01365.html][Installing
> Org through the new http://orgmode.org ELPA]]
>
> -
> [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00316.html][latest
> org from Elpa error: Invalid function: org-babel-header-a]]
>
> -
> [[https://lists.defectivebydesign.org/archive/html/emacs-orgmode/2015-08/msg00318.html][Re:
> [O] wrong type argument listp... org-element-set-contents]]

Package.el did not attempt to avoid those problems until:

    commit 67c6906a5f2e79ef771a1d7c8abeb29eb633c659
    Author: Artur Malabarba <bruce.connor.am@gmail.com>
    Date:   Thu Dec 3 14:50:09 2015 +0000

So the above examples may be "long fixed by now".

Then again, maybe not, or not all.

notice that the above commit doesn't only try to make it so the
installed package is compiled correctly (which is admittedly the most
important concern) but also to make it so the running Emacs session is
upgraded to the new package without having to re-start.


        Stefan

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Nick, thank you for your reply.

> On Nov 27, 2019, at 4:15, Nick Dokos <ndokos@gmail.com> wrote:
> 
> Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org> writes:
> 
>> org 9.1.9 is a built-in
>> 
>> but org 9.2.6 comes as a dependency to some packages and having both installed creates conflicts.
>> 
> 
> What conflicts are you seeing?

At one point I was unable to archive subtrees because some function was undefined.
I uninstalled 9.2.6 and the issues was fixed.

> I have the built-in 9.1.9 org that
> comes with emacs but I run (close to) latest master and I see no
> problems:

Obviously you are not the typical user... :)

What should happen is that
1) packages.el should see that I'm trying to install a package that requires 9.2.6 as a dependency and it should notify me that 9.1.9 is already installed and do I really want to do that, etc.

2) *or* just consider that it's better for me to use 9.2.6 instead of whatever comes with emacs and make sure that the older package is forgotten by emacs.

But honestly, I think 1) should be the default for any package.


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: org 9.2.6 and org 9.1.9

[Stefan Monnier]

> What should happen is that
> 1) packages.el should see that I'm trying to install a package that requires
> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> installed and do I really want to do that, etc.
>
> 2) *or* just consider that it's better for me to use 9.2.6 instead of
> whatever comes with emacs and make sure that the older package is forgotten
> by emacs.

I think 2 is the right option.  package.el was designed such that you
can have various versions of a given package installed.  Only one of the
can be activated at any given time, because Emacs Lisp doesn't provide any
way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
should be a perfectly normal situation.

Any misbehavior that results from this should be reported as a bug
(especially if it can be reproduced).


        Stefan

Re: org 9.2.6 and org 9.1.9

[Jean-Christophe Helary]

Thank you Stefan. I'll try to reproduce the issue and then I'll report.

Jean-Christophe

> On Nov 27, 2019, at 12:24, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> What should happen is that
>> 1) packages.el should see that I'm trying to install a package that requires
>> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
>> installed and do I really want to do that, etc.
>> 
>> 2) *or* just consider that it's better for me to use 9.2.6 instead of
>> whatever comes with emacs and make sure that the older package is forgotten
>> by emacs.
> 
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
> 
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).
> 
> 
>        Stefan

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

I would agree that org should be a package in elpa and not bundled into
emacs core. The user can then choose which version to install (ignoring the
package dependency problem). This won't fix all the issues as anyone
installing a new major version when an existing version is already loaded
will run into the same problems. Bottom line, as org stands now, upgrading
when org is already loaded is problematic.

On Wed, 27 Nov 2019 at 16:44, Jean-Christophe Helary <
jean.christophe.helary@traduction-libre.org> wrote:

> Thank you Stefan. I'll try to reproduce the issue and then I'll report.
>
> Jean-Christophe
>
> > On Nov 27, 2019, at 12:24, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
> >
> >> What should happen is that
> >> 1) packages.el should see that I'm trying to install a package that
> requires
> >> 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> >> installed and do I really want to do that, etc.
> >>
> >> 2) *or* just consider that it's better for me to use 9.2.6 instead of
> >> whatever comes with emacs and make sure that the older package is
> forgotten
> >> by emacs.
> >
> > I think 2 is the right option.  package.el was designed such that you
> > can have various versions of a given package installed.  Only one of the
> > can be activated at any given time, because Emacs Lisp doesn't provide
> any
> > way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> > should be a perfectly normal situation.
> >
> > Any misbehavior that results from this should be reported as a bug
> > (especially if it can be reproduced).
> >
> >
> >        Stefan
>
>

-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> I would agree that org should be a package in elpa and not bundled into emacs core. The user can then choose which version to install (ignoring the package dependency problem).

I disagree with removing Org-mode from Emacs core, as I've explained elsewhere.

> This won't fix all the issues as anyone installing a new major version when an existing version is already loaded will run into the same problems. Bottom line, as org stands now, upgrading when org is already loaded is problematic.

It would be very unfortunate if we removed Org-mode from Emacs core
with the sole motivation to band-aid an issue with upgrading packages
in package.el.

So I would put your above argument more bluntly: removing Org-mode
from Emacs core would be to sweep the problem under the rug.
package.el is still broken.

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Tim Cross]

[-- Attachment #1: Type: text/plain, Size: 1493 bytes --]

But I don't think the issue is with package.el per se. You get the same
problem if you try to install org-mode manually without package.el. What is
really needed to fix this problem is some mechanism which will ensure all
org related definitions are somehow purged from the running instance before
attempting to install and compile a new version.  Provided there is no
org-mode functionality loaded when you install a later version with
package.el, it works fine.

On Wed, 27 Nov 2019 at 17:29, Stefan Kangas <stefan@marxist.se> wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
> > I would agree that org should be a package in elpa and not bundled into
> emacs core. The user can then choose which version to install (ignoring the
> package dependency problem).
>
> I disagree with removing Org-mode from Emacs core, as I've explained
> elsewhere.
>
> > This won't fix all the issues as anyone installing a new major version
> when an existing version is already loaded will run into the same problems.
> Bottom line, as org stands now, upgrading when org is already loaded is
> problematic.
>
> It would be very unfortunate if we removed Org-mode from Emacs core
> with the sole motivation to band-aid an issue with upgrading packages
> in package.el.
>
> So I would put your above argument more bluntly: removing Org-mode
> from Emacs core would be to sweep the problem under the rug.
> package.el is still broken.
>
> Best regards,
> Stefan Kangas
>


-- 
regards,

Tim

--
Tim Cross

[-- Attachment #2: Type: text/html, Size: 2068 bytes --]

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Tim Cross <theophilusx@gmail.com> writes:

> What is really needed to fix this problem is some mechanism which
> will ensure all org related definitions are somehow purged from the
> running instance before attempting to install and compile a new
> version.

That could be one way of going about it.  Other solutions have been
discussed in Bug#10125, for example here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125#59

> But I don't think the issue is with package.el per se. You get the
> same problem if you try to install org-mode manually without
> package.el.
[...]
> Provided there is no org-mode functionality loaded when you install
> a later version with package.el, it works fine.

As far as I understand, the bug in package.el is that you can't always
successfully install a later version of a package after it has been
loaded.  In this case, Org-mode fails to install properly.

Best regards,
Stefan Kangas

Re: org 9.2.6 and org 9.1.9

[Stefan Monnier]

> But I don't think the issue is with package.el per se.

Maybe it needs fixes elsewhere as well, but it's via package.el that the
problem is usually exposed.

> You get the same problem if you try to install org-mode manually
> without package.el.

Depends how you do it.

> What is really needed to fix this problem is some mechanism which will
> ensure all org related definitions are somehow purged from the running
> instance before attempting to install and compile a new version.

package.el does try to do that nowadays (in
`package--load-files-for-activation`).

It doesn't/can't handle all situations, but it should solve most of the
common issues.  Since it's virtually impossible to fix it 100%, we
depend on reports of actual problems in order to know what still needs
to be fixed (they need to be reproducible so we can figure out exactly
what happened, since it's not always obvious how best to avoid the
problem).


        Stefan

Re: org 9.2.6 and org 9.1.9

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 27 Nov 2019 07:29:24 +0100
> Cc: Jean-Christophe Helary <jean.christophe.helary@traduction-libre.org>,
>  Org-mode <emacs-orgmode@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> I disagree with removing Org-mode from Emacs core, as I've explained elsewhere.

I agree.  It would go against our previous decisions to have Org in
core, for reasons that IMO are not important enough to make such a
reversal.

Re: org 9.2.6 and org 9.1.9

[Fraga, Eric]

On Wednesday, 27 Nov 2019 at 17:00, Tim Cross wrote:
> I would agree that org should be a package in elpa and not bundled into
> emacs core. 

I would argue the opposite!  I would like to see org tightly integrated
into Emacs, in the same way that gnus now is.  Development of org would
be in step with the development of Emacs.  This would avoid any
dependency issues entirely.

But I have no problem with the current situation even if I have had to
be very careful in how I load org in my initialisation files...

-- 
Eric S Fraga via Emacs 27.0.50, Org release_9.2.6-552-g8c5a78

Re: org 9.2.6 and org 9.1.9

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > What should happen is that
> > 1) packages.el should see that I'm trying to install a package that requires
> > 9.2.6 as a dependency and it should notify me that 9.1.9 is already
> > installed and do I really want to do that, etc.
> >
> > 2) *or* just consider that it's better for me to use 9.2.6 instead of
> > whatever comes with emacs and make sure that the older package is forgotten
> > by emacs.
>
> I think 2 is the right option.  package.el was designed such that you
> can have various versions of a given package installed.  Only one of the
> can be activated at any given time, because Emacs Lisp doesn't provide any
> way to do better, but having both Org-9.1.9 and Org-9.2.6 installed
> should be a perfectly normal situation.
>
> Any misbehavior that results from this should be reported as a bug
> (especially if it can be reproduced).

I fully agree.  If package.el has a bug, we should fix it.

See also the previous discussion here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125

Best regards,
Stefan Kangas