From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Mon, 25 Jul 2016 20:06:23 +0300 Message-ID: <83k2g9tzow.fsf@gnu.org> References: <87y453sy0n.fsf@earth.catern.com> <87r3arripr.fsf@earth.catern.com> <874m7jygot.fsf@earth.catern.com> <83oa5ox21u.fsf@gnu.org> <123d2ae9-b523-5d5b-3bf8-c6e4462270b8@yandex.ru> <87a8h7wihs.fsf@earth.catern.com> <08e690b6-56a0-1182-2560-666e3bffb2ee@yandex.ru> <83wpkatpbv.fsf@gnu.org> <87a8h6nwea.fsf@earth.catern.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469466407 32685 80.91.229.3 (25 Jul 2016 17:06:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 17:06:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 19:06:47 2016 Return-path: Envelope-to: ged-emacs-devel@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 1bRjL4-0005Wd-Fb for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 19:06:46 +0200 Original-Received: from localhost ([::1]:33602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjL3-0004t6-Oj for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 13:06:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59601) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjKw-0004t1-TT for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:06:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRjKv-0004Zk-Rs for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:06:38 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjKv-0004Ze-OM; Mon, 25 Jul 2016 13:06:37 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1065 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bRjKu-0000AD-1I; Mon, 25 Jul 2016 13:06:36 -0400 In-reply-to: <87a8h6nwea.fsf@earth.catern.com> (sbaugh@catern.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:206127 Archived-At: > From: sbaugh@catern.com > Date: Mon, 25 Jul 2016 01:01:49 -0400 > > > One possible idea is to identify the programs that an environment > > would like to depend on it (like the compiler), define a variable for > > each one of them (compiler-program etc.), and then modify the > > corresponding commands to use that variable, if bound to non-nil, in > > preference to exec-path search. > > The environment also matters, so you'd need to have a > compiler-process-environment too. Sometimes, yes. But this is definitely for the project to set up. > Note: The compile command already makes use of a compilation-environment > variable. Then we already do what you want, right? > That would work, but again, it means updating the entire world to > support this. No, it means we need to make specific changes in specific primitives and infrastructure functions. Those which currently only look at exec-path, and are involved in invoking development tools for which we will want to provide this support. E.g., "M-x compile" will be able to invoke the compiler specified by the environment, "M-x gdb" will be able to invoke the debugger specified by the environment, etc. We could also have wrappers like call-compiler, call-debugger, etc. > Also, if we're going to update the world: Perhaps just add > buffer-local variables "local-exec-path" and > "local-process-environment", and flags like > "compile-use-local-environment" which if non-nil cause the relevant > command, when invoked, to use the local-exec-path and > local-process-environment variables from (current-buffer). That seems > more natural to me. But that's exactly the danger I think we should try to avoid: a Lisp application doesn't have good control of when buffer-local bindings will be in effect, because Emacs internals feel at liberty to temporarily switch to any buffer when they feel like it. These buffer-local bindings will bite you when you don't expect. That's why I think the environment should be only allowed to override file names of a specific limited set of tools, not the entire exec-path.