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, 18 Jul 2016 15:13:54 -0400 Message-ID: <87eg6qoj2l.fsf@earth.catern.com> References: <87y453sy0n.fsf@earth.catern.com> <87r3arripr.fsf@earth.catern.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1468869296 10189 80.91.229.3 (18 Jul 2016 19:14:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Jul 2016 19:14:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 18 21:14:48 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 1bPE04-0001pK-Al for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 21:14:44 +0200 Original-Received: from localhost ([::1]:49865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPE03-0006L4-Gi for ged-emacs-devel@m.gmane.org; Mon, 18 Jul 2016 15:14:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54183) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPDzX-0006Fy-MU for emacs-devel@gnu.org; Mon, 18 Jul 2016 15:14:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bPDzR-0005lh-OF for emacs-devel@gnu.org; Mon, 18 Jul 2016 15:14:10 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:53744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bPDzR-0005lQ-Gh for emacs-devel@gnu.org; Mon, 18 Jul 2016 15:14:05 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bPDzO-0001G2-B6 for emacs-devel@gnu.org; Mon, 18 Jul 2016 21:14:02 +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, 18 Jul 2016 21:14:02 +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, 18 Jul 2016 21:14:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 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:4XZb2+XtXcZPI/00+XtoQErYdd0= 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:205826 Archived-At: Stefan Monnier writes: > That was my assumption: your "environments" correspond to > specific subdirectories in the file-system. Nope, not necessarily. Python virtualenvs do have an associated directory that contains the installed libraries for that environment. But guix environment only updates environment variables to point to the locations of already existing libraries, and so guix environments don't exist in the filesystem at all. They're only a runtime thing. (Libraries are installed on demand at fixed paths when constructing an environment, and garbage-collected later) However, people do mostly use environments only when working on a specific project which exists in the filesystem, so I don't think it's too big of a compromise to start with. >> Does this approach (putting project root directories into >> file-name-handler-alist) sound like something that could be accepted >> into core Emacs? If so I'll get started. > > Hard to tell. Even the question is unclear to me. The approach > I suggest assumes you don't need/want to make changes to what I consider > "core" and instead use existing hooks (in this case > file-name-handler-alist). So it could be distributed via GNU ELPA, > for example. Oh, no, I do want to get this into Emacs. Because the use of these kind of environments is pretty common at this point, and it would be nice if Emacs natively understood them in a generic way. Then, yes, ELPA packages could build on that functionality to support specific kinds of environments. Same with the new project and xref functionality. > That seems to assume that an environment could be bound to a buffer > rather than a subdirectory, IOW it wouldn't be chained to > a subdirectory. Such environments seem to introduce further questions > about how to determine which env to use for which buffer (IOW what UI > to expose to the user). If an environment is manually set for the current buffer, then use that one for all commands run. Otherwise, if a buffer is visiting a file in a project, check for a manually set or automatically detected environment for that project, then use that environment for all commands run. Otherwise, use the global environment for all commands run. That seems like a decent UI. But in the manually set case, it is tricky to implement, because of the related buffers problem... > You could set file-name-handler-alist buffer-locally, maybe? > > Still, the main issue is what to do about things that happen in other > buffers but which the user would consider as related. Yes, otherwise just buffer-local exec-path and process-environment would work okay. > You mean you want it distributed with Emacs? Most new packages nowadays > end up in GNU ELPA rather than in Emacs, unless they offer functionality > needed by other packages that are distributed with Emacs. Yes, I think this is important functionality that other packages distributed with Emacs should be able to build on. Using virtualenvs is very common for Python, for example, and Emacs should support that. Also, since this is a headline feature of GNU Guix, it would be nice to support it in GNU Emacs.