From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: sbaugh@catern.com Newsgroups: gmane.emacs.devel Subject: Re: Managing environments (Python venv, guix environment, etc.) Date: Sat, 30 Jul 2016 09:30:59 -0400 Message-ID: <8760rnckx8.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> <87bn1gnx4q.fsf@earth.catern.com> <834m78qnh5.fsf@gnu.org> <87zip0cgc5.fsf@earth.catern.com> <83wpk3poj9.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1469886700 32191 80.91.229.8 (30 Jul 2016 13:51:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 30 Jul 2016 13:51:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 30 15:51:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bTUeN-0007o2-F2 for ged-emacs-devel@m.gmane.org; Sat, 30 Jul 2016 15:49:59 +0200 Original-Received: from localhost ([::1]:35608 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTUN0-0002Z9-E8 for ged-emacs-devel@m.gmane.org; Sat, 30 Jul 2016 09:32:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33174) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTUMR-0002Yg-Se for emacs-devel@gnu.org; Sat, 30 Jul 2016 09:31:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bTUMN-00077l-N7 for emacs-devel@gnu.org; Sat, 30 Jul 2016 09:31:26 -0400 Original-Received: from blaine.gmane.org ([80.91.229.8]:37855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bTUMN-00077d-Fy for emacs-devel@gnu.org; Sat, 30 Jul 2016 09:31:23 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bTUMA-0006jk-9u for emacs-devel@gnu.org; Sat, 30 Jul 2016 15:31:10 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:CcvnyEvWw+0CyEGTmruvFEa7fkc= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.229.8 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:206243 Archived-At: Eli Zaretskii writes: > And having read all that, I still don't see why we would like to use > file-name handlers for supporting these features. My suggestion to > embed such support directly in the affected primitives, like > process-file, call-process, etc., still stands. Would you please > consider this possibility, and if you think it's inappropriate, > explain why you think so? I think I missed the suggestion when you made it earlier (or don't recognize it as the same suggestion now) and I'm not sure I understand it in this condensed form. Could you elaborate? In particular I'm missing how directly adding environment support in process-file etc. will handle the issue of, e.g., a user invoking M-x compile, where we need to communicate the environment to use between buffers. > If you want an environment to be able to change its locale, then we > must also pay attention to the following subtlety: the value of > process-environment is stored by Emacs in its original undecoded form, > i.e. in the encoding used by the "pre-existing environment"s codeset. > Thus, supporting locale changes seem to require a separate variable > that is used in preference to process-environment, and whose value is > encoded according to the customized locale. Hmm, it's indeed tricky that as locale changes, the encoding of all other environment variables also needs to change (if I understand you correctly). It was probably a bad example though because I doubt that any environment-creating tools will set a different locale. If there are some that do, it might be useful to look at what they do to handle this... > Would having a single user variable for controlling the above be a > sufficiently nice UI? If not, why not? A single user variable controlling what environment we are in? Meaning that Emacs is only ever in exactly one environment? That is not adequate, it makes it difficult to work on different projects in the same Emacs. And anyway a single environment approach can already be done easily enough by writing a command to just swap between different values for process-environment, exec-path, and so on. >> However, TRAMP also needs to be able to support running processes on >> remote hosts. And there its mechanism is rather unnatural - why >> should we use a filename to identify the remote host on which we want to >> run a process? > > In the context of running processes on remote hosts, this is actually > very natural. It allows Lisp applications to be stateless in this > regard. > > By contrast, environments support cannot be stateless, because by the > very definition, when a command is executed in a certain environment, > then _all_ of the files and environment variables should be as the > environment defines. In what way does this allow statelessness, that it doesn't also allow for environments? This mechanism allows a Lisp application to ignore whether there is currently a connection to a remote host, when trying to run a process on a remote host, since the connection will be created by TRAMP automatically - is that what you mean by stateless? Environment usage can be just as stateless. The custom environment identifier embedded into the file name can and should be enough information to locate the configuration for the environment, load it into Emacs, and start using it. Thus a Lisp application trying to run a process in an environment can ignore whether the environment is currently in use by Emacs.