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 13:59:33 -0400 Message-ID: <87bn1gnx4q.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469815221 23089 80.91.229.3 (29 Jul 2016 18:00:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 18:00:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 20:00:12 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 1bTC4v-0008JZ-Ln for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 20:00:09 +0200 Original-Received: from localhost ([::1]:60883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTC4p-0000Pa-M6 for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 14:00:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTC4j-0000PL-58 for emacs-devel@gnu.org; Fri, 29 Jul 2016 13:59:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTC4e-0005wl-DL for emacs-devel@gnu.org; Fri, 29 Jul 2016 13:59:56 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:60709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTC4e-0005tL-5k for emacs-devel@gnu.org; Fri, 29 Jul 2016 13:59:52 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bTC4R-00087K-UJ for emacs-devel@gnu.org; Fri, 29 Jul 2016 19:59:39 +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 19:59:39 +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 19:59:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 41 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:h4aWya+nLUaw0pQCRAN5wKr8KTk= 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:206226 Archived-At: Eli Zaretskii writes: > It may seem to you that remote access is similar to a different > environment, but in fact they are very different. Environment is not > a property of a file name, it is a property of a project. Environment is not a property of a project either, it's something else entirely. A project doesn't necessarily have an environment associated with it, and an environment isn't necessarily asociated with a project. Treating it as a property of a file name or a property of a project are just two possible interfaces/implementations; both will limit the user. Remote access was turned into a property of a file name by embedding the remote host identifier into the file name. If we embed the environment into the file name, then the environment also becomes a property of a file name. > Moreover, past attempts I know about to use file handlers for > processing local files turned out to have subtle misfeatures. I would be interested to see previous failed attempts to use file handlers on local files, can you point me to an example? AFAIK jka-compr.el works fine. > Even more importantly, the _conceptual_ difference is huge, and it's > bound to bite us in the long run, because people who work on the > file-name handlers has the remote-access concept on their mind, and > will write code that caters to those use cases, so we will sooner or > later end up with code that subtly breaks in the environment use > cases. That is a very fair point, but I think the current state of file-name handlers is functional for the environment use-case. And so if it works out, not breaking environment.el can be considered in future modifications to file-name handlers. Anyway, isn't the file-name handler interface a generic way to abstract over access to the underlying operating system, not just a method for implementing remote-access? Wouldn't a change that caused file-name handlers to be only usable for remote acces, be a bug?