From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Mon, 25 Jul 2016 01:01:49 -0400 Message-ID: <87a8h6nwea.fsf@earth.catern.com> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469422947 26069 80.91.229.3 (25 Jul 2016 05:02:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 05:02:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 07:02:12 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 1bRY1r-00056B-UZ for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 07:02:12 +0200 Original-Received: from localhost ([::1]:58653 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRY1r-0000yY-5b for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 01:02:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRY1k-0000xO-3M for emacs-devel@gnu.org; Mon, 25 Jul 2016 01:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRY1f-0004tg-VY for emacs-devel@gnu.org; Mon, 25 Jul 2016 01:02:03 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRY1f-0004tc-P4 for emacs-devel@gnu.org; Mon, 25 Jul 2016 01:01:59 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bRY1e-0004uR-0h for emacs-devel@gnu.org; Mon, 25 Jul 2016 07:01:58 +0200 Original-Received: from 71-46-80-67.res.bhn.net ([71.46.80.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Jul 2016 07:01:57 +0200 Original-Received: from sbaugh by 71-46-80-67.res.bhn.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 25 Jul 2016 07:01:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 26 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 71-46-80-67.res.bhn.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Cancel-Lock: sha1:WhNfZAQ7RwDnKZnje9jkYo++qGA= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:206105 Archived-At: Eli Zaretskii writes: >> Like Eli said, this seems unwise. But it hints at a logical problem: if >> start-process and friends are simply documented to use exec-path and >> process-environment, but use their modified values in some >> circumstances, someone trying to debug this could have a big problem. > > 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. Note: The compile command already makes use of a compilation-environment variable. That would work, but again, it means updating the entire world to support this. 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.