org 9.2.6 and org 9.1.9

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

org 9.2.6 and org 9.1.9

Jean-Christophe Helary-4
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



Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Tim Cross-5
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 <[hidden email]> wrote:
Jean-Christophe Helary <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Jean-Christophe Helary-4
In reply to this post by Jean-Christophe Helary-4
Nick, thank you for your reply.

> On Nov 27, 2019, at 4:15, Nick Dokos <[hidden email]> wrote:
>
> Jean-Christophe Helary <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

RE: org 9.2.6 and org 9.1.9

Cook, Malcolm
In reply to this post by Tim Cross-5
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 :
 
 
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=[hidden email]> On Behalf Of Tim Cross
Sent: Tuesday, November 26, 2019 3:41 PM
To: Nick Dokos <[hidden email]>
Cc: Org-mode <[hidden email]>; Emacs developers <[hidden email]>
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 <[hidden email]> wrote:

Jean-Christophe Helary <[hidden email]> 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

 

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Jean-Christophe Helary-4


> On Nov 27, 2019, at 11:59, Cook, Malcolm <[hidden email]> 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=[hidden email]> On Behalf Of Tim Cross
> Sent: Tuesday, November 26, 2019 3:41 PM
> To: Nick Dokos <[hidden email]>
> Cc: Org-mode <[hidden email]>; Emacs developers <[hidden email]>
> 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 <[hidden email]> wrote:
> Jean-Christophe Helary <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Monnier
In reply to this post by Jean-Christophe Helary-4
> 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


Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Jean-Christophe Helary-4
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Tim Cross-5
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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Kangas
In reply to this post by Jean-Christophe Helary-4
Jean-Christophe Helary <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Kangas
In reply to this post by Tim Cross-5
Tim Cross <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Kangas
In reply to this post by Stefan Monnier
Stefan Monnier <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Tim Cross-5
In reply to this post by Stefan Kangas
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 <[hidden email]> wrote:
Tim Cross <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Eric S Fraga
In reply to this post by Tim Cross-5
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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Kangas
In reply to this post by Tim Cross-5
Tim Cross <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Monnier
In reply to this post by Tim Cross-5
> 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


Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Monnier
In reply to this post by Cook, 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/%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


Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Eli Zaretskii
In reply to this post by Stefan Kangas
> From: Stefan Kangas <[hidden email]>
> Date: Wed, 27 Nov 2019 07:29:24 +0100
> Cc: Jean-Christophe Helary <[hidden email]>,
>  Org-mode <[hidden email]>, Emacs developers <[hidden email]>
>
> 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.

Reply | Threaded
Open this post in threaded view
|

RE: org 9.2.6 and org 9.1.9

Cook, Malcolm
In reply to this post by Stefan Monnier

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/%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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Tim Cross-5
>> 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 <[hidden email]> 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/%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

Reply | Threaded
Open this post in threaded view
|

Re: org 9.2.6 and org 9.1.9

Stefan Monnier
In reply to this post by Cook, Malcolm
> [[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 <[hidden email]>
    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