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: Wed, 27 Jul 2016 20:47:42 -0400 Message-ID: <878twmpp01.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> <83shuzt8iz.fsf@gnu.org> <87y44rudzi.fsf@earth.catern.com> <834m7evry3.fsf@gnu.org> <87oa5mvotr.fsf@earth.catern.com> <83zip6u8v1.fsf@gnu.org> <87zip6nwx1.fsf@earth.catern.com> <83lh0ptzrd.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469666892 20329 80.91.229.3 (28 Jul 2016 00:48:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Jul 2016 00:48:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 28 02:48:03 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 1bSZUZ-0001om-Kv for ged-emacs-devel@m.gmane.org; Thu, 28 Jul 2016 02:48:03 +0200 Original-Received: from localhost ([::1]:50239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSZUY-0004LA-Nt for ged-emacs-devel@m.gmane.org; Wed, 27 Jul 2016 20:48:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSZUT-0004L2-JQ for emacs-devel@gnu.org; Wed, 27 Jul 2016 20:47:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bSZUP-0000Ss-Dk for emacs-devel@gnu.org; Wed, 27 Jul 2016 20:47:56 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:48184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bSZUP-0000SQ-6O for emacs-devel@gnu.org; Wed, 27 Jul 2016 20:47:53 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bSZUL-0001lW-Jb for emacs-devel@gnu.org; Thu, 28 Jul 2016 02:47:50 +0200 Original-Received: from cpe-66-108-244-72.nyc.res.rr.com ([66.108.244.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Jul 2016 02:47:49 +0200 Original-Received: from sbaugh by cpe-66-108-244-72.nyc.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Jul 2016 02:47:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 25 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-66-108-244-72.nyc.res.rr.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Cancel-Lock: sha1:cr1Pq3ThdvJzGzONLyH2hxpIJ4g= 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:206199 Archived-At: Eli Zaretskii writes: > See, the above 2 paragraphs contradict each other. The second one is > precisely the kind of breakage I had in mind and feared of, and I see > now that we are in violent agreement regarding such a possibility. > > Prepending directories to PATH doesn't solve these problems. E.g., if > the prepended directory holds a version of gzip that is "broken" in > the above-mentioned meaning in the environment of a project, then > Emacs will be unable to visit gzip-compressed files, such as Info > manuals and its own Lisp sources. > > I think we need to avoid this danger. That is all true. I was of the opinion that it was not quite so dangerous because this method worked fine most of the time for shells. But I agree now - we should be careful, and abide by higher standards. And I think the suggestion I made in the email I sent just before this, to use a new kind of magic path, and thereby reuse all the process-file infrastructure, is the best way to be careful in this matter. Only the programs that can and should be run remotely, use process-file; and I contend that those programs are exactly and exclusively the things we want to run inside a custom environment.