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: Sun, 24 Jul 2016 17:24:20 +0300 Message-ID: <83vazvt8q3.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469370289 3498 80.91.229.3 (24 Jul 2016 14:24:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jul 2016 14:24:49 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 24 16:24: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 1bRKKl-0000Ok-8z for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2016 16:24:47 +0200 Original-Received: from localhost ([::1]:56205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRKKk-0000LL-Ax for ged-emacs-devel@m.gmane.org; Sun, 24 Jul 2016 10:24:46 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRKKB-0000L7-E1 for emacs-devel@gnu.org; Sun, 24 Jul 2016 10:24:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRKK7-0008O5-Bx for emacs-devel@gnu.org; Sun, 24 Jul 2016 10:24:11 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRKK7-0008O1-91; Sun, 24 Jul 2016 10:24:07 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3394 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bRKK6-0003Bh-B0; Sun, 24 Jul 2016 10:24:06 -0400 In-reply-to: <123d2ae9-b523-5d5b-3bf8-c6e4462270b8@yandex.ru> (message from Dmitry Gutov on Sun, 24 Jul 2016 06:26:41 +0300) 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:206083 Archived-At: > Cc: emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sun, 24 Jul 2016 06:26:41 +0300 > > On 07/23/2016 10:10 AM, Eli Zaretskii wrote: > > Actually, I don't like to see any feature, let alone a core one, use > > file-name-handler-alist for local files. Lots of code in Emacs, > > including primitives, really handle such files as remote, so the > > results are likely to be incorrect and subtly broken. > > We do have file-remote-p, don't we? Maybe the code in question should be > fixed. No, I meant that we assume these are remote files without testing, e.g. that primitives which support local files, like expand-file-name, don't DTRT for them. The code is written with that assumption in mind. > > I always thought that features like this one should use and extent > > the infrastructure in project.el. And yet Dmitry is silent in this > > discussion. What am I missing? > > I don't know exactly if project.el is the best place for it. Maybe we > should see how well environment.el works as a separate feature, and if > that makes sense, incorporate it after. It would sound strange to me that project.el fails to support essentially the first serious client of its intended audience. > My main concern with this proposal is avoiding to have to purposefully > modify "every Elisp package that runs processes". Right. Which is why I thought we should come up with some reasonable way of supporting that without infecting "every package". > If every process call will pass through the environment dispatcher, > that's bound to add some overhead. How will that affect the code > that makes multiple process calls at once, such as VC? I'd like to > see some numbers. > > And if we base this feature on project.el right away, it will add a > stricter requirement on the performance of `project-current', which is > currently called at most once per user command. We could add some cache > there, of course. > > Alternatively, we can keep environment.el separate, and any advanced > minor mode, such as EDE, would both hook into project.el and set up any > necessary environment.el variables. I actually am not sure what exactly is required by environment.el. This discussion started by talking about environment variables, but somehow we are now talking about such core functionality as load-path and exec-path. The latter is a far cry from the former, IMO. I'm not sure how we made that leap in the discussion.