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:04:54 +0300 Message-ID: <83lh0ptzrd.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469466334 31591 80.91.229.3 (25 Jul 2016 17:05:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 17:05:34 +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:05:24 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 1bRjJj-0004Yg-UL for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 19:05:24 +0200 Original-Received: from localhost ([::1]:33598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjJj-0004Aq-2Y for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 13:05:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjJc-0004AW-GI for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:05:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRjJY-0004Ce-CX for emacs-devel@gnu.org; Mon, 25 Jul 2016 13:05:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRjJY-0004CU-AA; Mon, 25 Jul 2016 13:05:12 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1064 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bRjJW-0005EH-9g; Mon, 25 Jul 2016 13:05:11 -0400 In-reply-to: <87zip6nwx1.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:206126 Archived-At: > From: sbaugh@catern.com > Date: Mon, 25 Jul 2016 00:50:34 -0400 > > > IOW, I simply fail to see how we will be able to avoid disrupting the > > most basic features if we modify exec-path. Even visiting a file can > > fire up a subprocess -- how do we make sure the right program for that > > will still be found, if we let some project's environment mess with > > exec-path behind the user's back? And what about spellers (e.g., for > > ispell-check-comments-and-strings)? Etc. etc. > > I don't think that would be an issue. At the moment, the primary place > to use these kind of special environments is a Unix shell. If basic > tools like coreutils weren't in the environment, the environment would > already be useless for the user. And the only way to get some kind of > useless environment like that would be to explicitly configure it; I'm > inclined to call that user error. Also: These special environments > typically just prepend new directories to PATH and other vars, > "inheriting" the binaries that were in the user's pre-existing > environment, and just overriding some, so in the typical case things > will certainly work fine. > > Also note: If a binary from outside some project-specific environment is > run within that environment, it might break. (Maybe you preload some > crazy library within the project-specific environment, and have a set of > project-specific binaries that know how to cope with that.) 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. > So if we don't modify exec-path to be project-specific, then anything > that wants to run a process inside the project-specific environment > would need to be explicitly modified to search the project-specific > path, to avoid running outside binaries inside the special > environment. I think the suggestion to define a series of variables, which, if non-nil, will override the exec-path search by the relevant primitives, avoids this issue, because these variables will be handled on the infrastructure level. > > Once again, why not use locate-file? CEDET and EDE already do, and I > > assume for good reasons. > > Yes, a new program that wants to search per-environment search paths > could use locate-file. But I still hope for not needing to modify things > to be environment-aware. We cannot avoid some modifications anyway. You are talking about changing Emacs on a very low and delicate level. > > More generally, why would a project want to modify exec-path? to find > > which programs? Is it only the compiler/interpreter of the > > programming language used by the project, or something else as well, > > and why? E.g., I don't really understand your example with browse-url > > -- why would I want to change a browser as function of the project I'm > > working on? > [...] > maybe if you're developing a browser, you'd want browse-url to pick > up the version compiled in the project-specific environment when > you're working on it. browse-url already has browse-url-*-program and browse-url-default-browser variables that should be enough to cater to this use case. A project can simply customize their values, and make them buffer-local if needed. > In general I think it's entirely reasonable to want to be able to run > project-specific version of developer tools. The compiler/interpreter is > the most obvious project-specific program, but there are benefits to > supporting running every developer tool inside the project-specific > environment. But exec-path is not just for development tools. It's for _any_ program Emacs might need to run. Thus changing it has an effect that is much more wide and prominent. > Here are three benefits that I see for running everything within the > project-specific environment by default: > - This works identically (and therefore compatibly) to the Unix shell > inside a special environment. Actually, many development environments are configured by pointing at specific absolute file names of the tools, such that any changes in PATH don't affect them. > - Any other project-specific developer tools that we don't know about or > don't yet exist, will be automatically supported. > - And most importantly: all the myriad programming modes for Emacs with > their many custom methods for running their compiler/interpreter, will > automatically support running their compilers/interpreters in an > environment-aware way. I think the downsides of this are too serious to ignore. Like this one, for example: > However I admit that if the user wants to run a development program from > outside the project-specific environment (or even a development program > from another environment) it could become a little more tricky... More generally, running _any_ program that doesn't belong to the environment might subtly break. > And the conceptually easiest way is still just updating Elisp commands > (such as compile or shell-command) one by one to be environment-aware. The challenge is to make changes to the infrastructure that cover the 80% of use cases in environment-aware development, without making the cure worse than the disease.