From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Monnier Subject: bug#10125: RFE: require and load-path-shadowing Date: Thu, 10 Jan 2013 20:57:41 -0500 Message-ID: References: <87sj68eogm.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:58186) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtTsf-00035S-GU for emacs-orgmode@gnu.org; Thu, 10 Jan 2013 20:58:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtTsc-0005CF-Oy for emacs-orgmode@gnu.org; Thu, 10 Jan 2013 20:58:01 -0500 Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-Message-ID: In-Reply-To: (Glenn Morris's message of "Thu, 10 Jan 2013 18:43:43 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Glenn Morris Cc: Achim Gratz , 10125@debbugs.gnu.org >> 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