From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357869495 15396 80.91.229.3 (11 Jan 2013 01:58:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jan 2013 01:58:15 +0000 (UTC) Cc: Achim Gratz , 10125@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jan 11 02:58:32 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TtTt7-0005Sd-3l for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Jan 2013 02:58:29 +0100 Original-Received: from localhost ([::1]:49800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtTsq-0003KC-S2 for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Jan 2013 20:58:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtTsm-0003CO-G0 for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 20:58:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TtTsj-0005DN-02 for bug-gnu-emacs@gnu.org; Thu, 10 Jan 2013 20:58:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49338) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TtTsc-0005CB-L7; Thu, 10 Jan 2013 20:57:58 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TtTsf-0003bi-QI; Thu, 10 Jan 2013 20:58:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org, emacs-orgmode@gnu.org Resent-Date: Fri, 11 Jan 2013 01:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10125 X-GNU-PR-Package: emacs,org-mode X-GNU-PR-Keywords: Original-Received: via spool by 10125-submit@debbugs.gnu.org id=B10125.135786947413852 (code B ref 10125); Fri, 11 Jan 2013 01:58:01 +0000 Original-Received: (at 10125) by debbugs.gnu.org; 11 Jan 2013 01:57:54 +0000 Original-Received: from localhost ([127.0.0.1]:54802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtTsX-0003bN-UR for submit@debbugs.gnu.org; Thu, 10 Jan 2013 20:57:54 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:41445) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TtTsW-0003b9-Ab for 10125@debbugs.gnu.org; Thu, 10 Jan 2013 20:57:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAG6Zu09MCpYP/2dsb2JhbABEgXuyFoEIghUBAQQBViMFCwsOJhIUGA0kLoduBQu5fpBEA4hCjWiNCYFYgwc X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="212270208" Original-Received: from 76-10-150-15.dsl.teksavvy.com (HELO pastel.home) ([76.10.150.15]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 10 Jan 2013 20:57:42 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D2F28592BE; Thu, 10 Jan 2013 20:57:41 -0500 (EST) In-Reply-To: (Glenn Morris's message of "Thu, 10 Jan 2013 18:43:43 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:69586 Archived-At: >> 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