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: Fri, 29 Jul 2016 16:57:46 -0400 Message-ID: <87zip0cgc5.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> <87lh0qry9j.fsf@gmx.de> <87eg6hswd2.fsf@gmx.de> <87popypr3s.fsf@earth.catern.com> <83zip1rfhk.fsf@gnu.org> <87bn1gnx4q.fsf@earth.catern.com> <834m78qnh5.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469825909 29681 80.91.229.3 (29 Jul 2016 20:58:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 20:58:29 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 22:58:20 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 1bTErM-00025v-4H for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 22:58:20 +0200 Original-Received: from localhost ([::1]:33247 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTErG-00060M-53 for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 16:58:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34599) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTEr9-000604-IP for emacs-devel@gnu.org; Fri, 29 Jul 2016 16:58:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTEr5-0005Ga-De for emacs-devel@gnu.org; Fri, 29 Jul 2016 16:58:06 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:39714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTEr5-0005FX-2d for emacs-devel@gnu.org; Fri, 29 Jul 2016 16:58:03 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bTEqv-0001vF-PM for emacs-devel@gnu.org; Fri, 29 Jul 2016 22:57:53 +0200 Original-Received: from cpe-24-193-43-192.nyc.res.rr.com ([24.193.43.192]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2016 22:57:53 +0200 Original-Received: from sbaugh by cpe-24-193-43-192.nyc.res.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 29 Jul 2016 22:57:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 100 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cpe-24-193-43-192.nyc.res.rr.com User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Cancel-Lock: sha1:X98fbq4cBWN48Q1YblyWkGXivCU= 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:206233 Archived-At: Eli Zaretskii writes: > Then perhaps it's time to clarify what an environment really is? I > don't think that has been done in this discussion; if I missed > something, please point that out. An environment is a collection of environment variables paired with values for those variables. A program is said to run in the environment when it runs with those environment variables set to those values. Other environment variables might be set to arbitrary values. A program is running in a (making up some jargon for this thread): - "pure environment" if the only environment variables set are those specified in the environment. - "combined environment" if environment variables are set to a combination of values from two different environments; generally, a combination of a custom environment and the pre-existing environment. The custom environment values are generally prepended to the pre-existing environment values, which means the custom environment search paths will be searched first. A program running in a Unix distribution uses some environment variables ("search paths") to locate distribution resources and some environment variables ("configuration variables") to determine its configuration. For example, PATH is a search path for executables, LIBRARY_PATH is a search path for libraries, and LANG is a configuration variable containing the name of the current locale. The typical Unix distribution has some default environment in which programs run to access the default resources and configuration of the distribution. The "pre-existing environment" is the one which a program started in; generally this is inherited from the program's parent process without modification. An interesting "custom environment" is an environment containing settings which are not default for the Unix distribution on which the environment is being used. Instead, a custom environment contains settings for search paths which point to directories that contain some custom binaries and libaries, and settings for configuration variables to further manipulate the behavior of programs running within the custom environment. Custom environments are useful for development because they allow developing and compiling programs in a portable, reproducible, site-local-configuration-independent way. They are useful also for distribution by allowing finnicky software to run in an environment that is exactly what it expects. (These use cases are similar to how chroots and containers are used, though environments are clearly lighter-weight) Supporting the use of custom environments in Emacs is the point of this mailing list thread. Custom environments are (generally) what I have been referring to when I've said "environment" in this thread. environment.el would allow using a given "custom environment" to run a program in Emacs in either a "pure environment", or a "combined environment" created from the custom environment and the "pre-existing environment" of Emacs. Ideally, environment.el would provide a nice user interface for doing that. >> If we embed the environment into the file name, then the environment >> also becomes a property of a file name. > > But since an environment is not a property of a file name, doing that > would be a mistake, it seems. Sorry, I don't think I was clear. TRAMP has the function of visiting files located on remote hosts, and it needs to identify the files located on remote hosts. To do this, it combines an identifier for the remote host, with the filename of the file on the remote host, and then using that combination as the filename within Emacs. For environment.el, there is no analogous need to identify files located inside environments, since the files "located" within an environment are exactly the same files with the same paths located outside the environment. (With one key exception - the meaning of ~ depends on the value of HOME in the environment. But that's minor.) However, TRAMP also needs to be able to support running processes on remote hosts. And there its mechanism is rather unnatural - why should we use a filename to identify the remote host on which we want to run a process? But we chose to do it, and I think it was a pretty good choice which results in pretty intuitive behavior in the rest of Emacs. Using a filename to identify the environment to run a process in is exactly as unnatural as this use of TRAMP, but I think it will result in equally intuitive behavior. By the way: In future work I would like to support editing files located inside chroots, containers, different mount namespaces, and so on. In all those cases it makes sense to have a magic prefix to identify where to look, and then the file name; and in all those cases the files could (eventually, with work in C) be directly visited on the local machine rather than transferred over the network. So in those cases it's very clear to me that file-name-handler-alist should be used, and since TRAMP basically assumes transferring files over the network/through a subprocess, a new file-name handler should be made. But all of those things are quite similar to environments, and it would be natural to reuse a magic prefix created for environments, to support those things. So that's another reason why using a magic prefix would be a sane choice for environments.