From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Glenn Morris <rgm@gnu.org>
Cc: Achim Gratz <Stromeko@nexgo.de>, 10125@debbugs.gnu.org
Subject: bug#10125: RFE: require and load-path-shadowing
Date: Thu, 10 Jan 2013 20:57:41 -0500 [thread overview]
Message-ID: <jwvvcb47bs0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <mthamoy574.fsf@fencepost.gnu.org> (Glenn Morris's message of "Thu, 10 Jan 2013 18:43:43 -0500")
>> There is currently a problem with package manager when a package is
>> installed from a package archive,that package is already installed
>> either in Emacs core or site-lisp, and when (parts of) said package have
>> already been loaded when ELPA tries to install: the byte-compiler will
>> use the already loaded definitions rather than the new ones from the
>> package to install.
> I guess this would be http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10125
Indeed, and as I mentioned back then I think it's a general enough
problem that we should try and think up a good solution.
Currently, we have two proposals:
1- run a separate Emacs instance: this gives you a clean slate, and lets
you compile in parallel, but runs into the difficulty of figuring out
exactly which clean slate to use.
I guess we could fork Emacs early on and keep this second process
around as a "process from which to generate new clean slates".
2- improve bytecomp.el to try and better isolate the compiled file from
the previously loaded packages.
I don't see a clear winner, but since I'm biased in favor of the second
(not sure why, to tell you the truth), I'll add a few points related to
it. The current behavior of bytecomp.el leads to various related
problems:
- outdated but already loaded packages can lead to mis-compilation.
for the bootstrap we try to workaround this with
byte-compile-refresh-preloaded, tho it only takes care of some
particular cases.
- outdated .elc file taking precedence over the new .el file can do
the same.
- bytecompiling a file affects the running session by side-effects such
as requiring packages.
- if a package calls `byte-compile' during its own compilation, this
sub-compilation will tend to complain about undeclared variables
because it doesn't know about the vars that have been defvar'd in the
outer compilation. That's one of the main reasons for cc-bytecomp's
hideous gymnastics.
Maybe we should (similarly to the fork idea above) keep a "clean
obarray", and run byte-compilations in a fresh copy of this
clean obarray.
I suggested a quick&dirty solution:
> > E.g. we could add to bytecomp.el the ability to force `require' to
> > reload a package if it's not already loaded from the file that
> > locate-library returns.
I still think it's not a bad option.
Of course, we'd still get trouble when the loading is not performed via
`require' but via autoload (maybe we could try and attack this problem
by allowing `autoload' to override an already existing definition, but
that could be delicate).
> That will probably work fine most of the time, but what if a package is
> restructed so that the feature names are different? Or a feature is
> removed?
I don't see why that would introduce a difficulty.
Stefan
prev parent reply other threads:[~2013-01-11 1:58 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87sj68eogm.fsf@Rainer.invalid>
[not found] ` <mthamoy574.fsf@fencepost.gnu.org>
[not found] ` <jwvvcb47bs0.fsf-monnier+emacs__21035.4545656175$1357869514$gmane$org@gnu.org>
2011-11-24 12:12 ` 24.0.91; package.el (org): Macros in tar packages & order of byte compilation Jambunathan K
2002-01-01 0:33 ` bug#10125: " Jambunathan K
2011-11-24 13:05 ` Eli Zaretskii
2011-11-24 17:22 ` Jambunathan K
2011-11-24 19:09 ` Glenn Morris
[not found] ` <v062i9tk0d.fsf@fencepost.gnu.org>
2011-11-24 19:53 ` Glenn Morris
2011-11-24 22:55 ` Stelian Iancu
2011-11-24 23:54 ` Glenn Morris
2011-11-25 3:31 ` Jambunathan K
2011-11-25 12:32 ` Stelian Iancu
[not found] ` <CAKvLAojUzYmrUF_64WXEbj9zmBjzZ4gn5cDYVqLTcik41PFJ7w@mail.gmail.com>
2011-11-25 12:58 ` Jambunathan K
2011-11-25 8:10 ` Eli Zaretskii
[not found] ` <hffwhdqov3.fsf@fencepost.gnu.org>
2011-11-25 12:15 ` Jambunathan K
2011-11-25 14:07 ` Chong Yidong
[not found] ` <87r50w47o3.fsf@gnu.org>
2011-11-25 14:57 ` Stefan Monnier
2011-11-25 19:15 ` Glenn Morris
2011-11-25 19:21 ` Glenn Morris
2011-11-25 18:19 ` Glenn Morris
2011-11-25 19:01 ` Glenn Morris
[not found] ` <83vcq88vwt.fsf@gnu.org>
2011-11-25 18:20 ` Glenn Morris
2013-01-11 16:06 ` bug#10125: RFE: require and load-path-shadowing Achim Gratz
[not found] ` <jwvvcb34qjg.fsf-monnier+emacs@gnu.org>
2013-01-11 16:56 ` Stefan Monnier
2013-01-11 19:53 ` Achim Gratz
2013-01-11 22:52 ` Stefan Monnier
[not found] ` <jwvlibz2v6e.fsf-monnier+emacs@gnu.org>
2013-01-12 8:15 ` Eli Zaretskii
2013-01-12 10:15 ` Achim Gratz
2013-01-12 13:34 ` Bastien
2013-01-12 14:03 ` Stefan Monnier
2013-01-12 14:23 ` Bastien
[not found] ` <87liby7a57.fsf@bzg.ath.cx>
2013-01-12 16:12 ` Stefan Monnier
2013-01-12 17:34 ` Bastien
2013-01-12 10:20 ` Achim Gratz
2013-01-12 12:07 ` Eli Zaretskii
2013-01-12 13:28 ` Stefan Monnier
[not found] ` <jwvehhqy1k8.fsf-monnier+emacs@gnu.org>
2013-01-12 13:55 ` Eli Zaretskii
[not found] ` <83wqvisdxx.fsf__30242.1131091707$1357998993$gmane$org@gnu.org>
[not found] ` <87ip72fi8f.fsf@Rainer.invalid>
2013-01-12 18:39 ` Eli Zaretskii
2013-01-12 18:42 ` Glenn Morris
[not found] ` <71vcb22qgz.fsf__38024.2966501557$1358016217$gmane$org@fencepost.gnu.org>
[not found] ` <87hamlbk3w.fsf__41794.7558024482$1358063310$gmane$org@Rainer.invalid>
[not found] ` <87hamis0js.fsf@Rainer.invalid>
2013-01-16 9:45 ` Kevin Rodgers
[not found] ` <kd5spq$1hh$1@ger.gmane.org>
2013-01-16 10:06 ` Andreas Schwab
[not found] ` <mvmtxqh5tn0.fsf@hawking.suse.de>
2013-01-16 14:59 ` Kevin Rodgers
2013-01-12 16:29 ` Achim Gratz
2013-01-12 17:01 ` Achim Gratz
2013-01-13 7:46 ` Achim Gratz
2013-01-13 7:52 ` Achim Gratz
2013-01-15 19:34 ` Achim Gratz
2013-01-11 2:45 ` Jambunathan K
2013-01-11 1:57 ` Stefan Monnier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvvcb47bs0.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=10125@debbugs.gnu.org \
--cc=Stromeko@nexgo.de \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).