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 00:50:34 -0400 Message-ID: <87zip6nwx1.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469422298 17344 80.91.229.3 (25 Jul 2016 04:51:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2016 04:51:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 25 06:51:30 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 1bRXrU-0005G5-KD for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 06:51:28 +0200 Original-Received: from localhost ([::1]:58621 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRXrT-0007FX-Lv for ged-emacs-devel@m.gmane.org; Mon, 25 Jul 2016 00:51:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53743) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRXqw-0007FN-Lc for emacs-devel@gnu.org; Mon, 25 Jul 2016 00:50:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRXqs-000307-GW for emacs-devel@gnu.org; Mon, 25 Jul 2016 00:50:53 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:42748) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRXqs-000302-8q for emacs-devel@gnu.org; Mon, 25 Jul 2016 00:50:50 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bRXqj-0004fF-PE for emacs-devel@gnu.org; Mon, 25 Jul 2016 06:50:41 +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 06:50:41 +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 06:50:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 71 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:rPmQyc38Uxa2WNgyea/R9a5We2Q= 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:206104 Archived-At: Eli Zaretskii writes: > 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.) 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. > 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. > 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? Well, also the build system and the debugger. And 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. 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. 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. - 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. 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... And the conceptually easiest way is still just updating Elisp commands (such as compile or shell-command) one by one to be environment-aware.