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: Managing environments (Python venv, guix environment, etc.) Date: Thu, 14 Jul 2016 17:36:08 -0400 Message-ID: <87y453sy0n.fsf@earth.catern.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468532343 15613 80.91.229.3 (14 Jul 2016 21:39:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jul 2016 21:39:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 14 23:38:56 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 1bNoLM-0007vu-GF for ged-emacs-devel@m.gmane.org; Thu, 14 Jul 2016 23:38:52 +0200 Original-Received: from localhost ([::1]:57137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNoLL-0008UJ-Hc for ged-emacs-devel@m.gmane.org; Thu, 14 Jul 2016 17:38:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37226) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNoJH-0007bI-6d for emacs-devel@gnu.org; Thu, 14 Jul 2016 17:36:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNoJB-0000YB-3w for emacs-devel@gnu.org; Thu, 14 Jul 2016 17:36:42 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:56952) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNoJA-0000Y5-T8 for emacs-devel@gnu.org; Thu, 14 Jul 2016 17:36:37 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bNoJ7-0006Df-Vo for emacs-devel@gnu.org; Thu, 14 Jul 2016 23:36:34 +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 ; Thu, 14 Jul 2016 23:36:33 +0200 Original-Received: from sbaugh by 71-46-80-67.res.bhn.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 Jul 2016 23:36:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 79 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:sF3snzyWJy6RBr+Rgd1Kkeps+9w= 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:205686 Archived-At: Hi emacs-devel, There are a number of tools which create a reproducible working environment for projects by changing environment variables such as PATH and LIBRARY_PATH to point at project-specific directories containing project-specific versions of libraries and executables. Two examples among many: Python's "virtualenv" and Guix's "guix environment". A typical shell-based workflow with these tools would involve starting your shell and activating the tool so it mutates your environment and puts you into the working environment specific to that project. With multiple terminals, one can have multiple shells open at the same time to work on multiple different projects each with a different environment. One could run several Emacs processes with different environments to work on different projects, but that's very painful. So I'm trying to teach Emacs how to handle multiple environments within the same process. Currently, Emacs can only operate in one environment at a time, since exec-path and process-environment are single global variables that are referenced directly by many different Elisp functions. Here's the ideal: The recently added support for projects in project.el is augmented to also know about the environment of those projects. When compile, async-shell-command, etc., are invoked in a buffer belonging to a project, the executed process is run with the environment defined for that project. Any other Elisp functions that inspect the environment should reference the environment defined for the current project. But I would count it as a failure if multiple-environment support required every Elisp package that runs processes to be explicitly modified to support it. Even just modifying everything in Emacs itself would be a major undertaking. So backwards-compatibility through some clever hacks is important. But I am only a humble novice, and am unsure about the best way to achieve this. Here are a few ideas I had: - Make exec-path and process-environment buffer-local I am told that this will cause a lot of bizarre behavior. In particular, I understand that this won't work with M-x compile, which reuses another buffer to run the compilation. - Make exec-path and process-environment a different kind of buffer-local dynamic variable The behavior of this variable would be that when it is defined locally in the current buffer, it behaves like a normal dynamic variable. And when it is not defined locally in the current buffer, looking up the variable will look up the variable dynamically instead of looking for a global value set with setq-default. This would mean that when M-x compile is invoked from some buffer, if exec-path and process-environment are not buffer-local in the compile buffer, those variables will be looked up dynamically, and found in the buffer-locals of the buffer that was current at the time of the M-x compile invocation. I don't know if this is possible given the implementation of dynamic variables in Emacs Lisp. - Use the same functionality as TRAMP, somehow TRAMP supports transparently running processes in multiple arbitrary environments (usually ones accessible over the network, but local environments should work too). But I'm not really familiar with how TRAMP works, so I'm not sure if it's possible to make use of its process-running capabilities without using magic filenames, and without copying files back and forth (an ugly overhead in this case since the files would all be local). - Use dir-locals I'm not sure how this could work, given the problems with making exec-path and process-environment buffer-local, but including it to be complete. If any of the great masters have suggestions about how to achieve this, I would greatly appreciate it. Thanks.