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: Fri, 29 Jul 2016 21:59:50 +0300 Message-ID: <834m78qnh5.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> <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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1469818828 15012 80.91.229.3 (29 Jul 2016 19:00:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Jul 2016 19:00:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: sbaugh@catern.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 29 21:00:17 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 1bTD16-0001cj-Fk for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 21:00:16 +0200 Original-Received: from localhost ([::1]:32914 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTD10-0003at-FT for ged-emacs-devel@m.gmane.org; Fri, 29 Jul 2016 15:00:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTD0u-0003Yr-J7 for emacs-devel@gnu.org; Fri, 29 Jul 2016 15:00:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTD0o-00011K-Sa for emacs-devel@gnu.org; Fri, 29 Jul 2016 15:00:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTD0o-00010S-Ol; Fri, 29 Jul 2016 14:59:58 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1886 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bTD0m-0006Wf-Rt; Fri, 29 Jul 2016 14:59:57 -0400 In-reply-to: <87bn1gnx4q.fsf@earth.catern.com> (sbaugh@catern.com) 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:206229 Archived-At: > From: sbaugh@catern.com > Date: Fri, 29 Jul 2016 13:59:33 -0400 > > 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. 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. > 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. > > 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? cygwin-mount, for one. > AFAIK jka-compr.el works fine. Because it takes great care not to touch anything that changes the semantics of file names: the file name still behaves the same with and without jka-compr. By contrast, AFAIU environments cannot do that by their very nature. > 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? No. > Wouldn't a change that caused file-name handlers to be only usable > for remote acces, be a bug? Yes, but the best way of fixing a bug is to avoid it in the first place.