all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: sbaugh@catern.com
Cc: emacs-devel@gnu.org
Subject: Re: Managing environments (Python venv, guix environment, etc.)
Date: Mon, 25 Jul 2016 20:04:54 +0300	[thread overview]
Message-ID: <83lh0ptzrd.fsf@gnu.org> (raw)
In-Reply-To: <87zip6nwx1.fsf@earth.catern.com> (sbaugh@catern.com)

> From: sbaugh@catern.com
> Date: Mon, 25 Jul 2016 00:50:34 -0400
> 
> > IOW, I simply fail to see how we will be able to avoid disrupting the
> > most basic features if we modify exec-path.  Even visiting a file can
> > fire up a subprocess -- how do we make sure the right program for that
> > will still be found, if we let some project's environment mess with
> > exec-path behind the user's back?  And what about spellers (e.g., for
> > ispell-check-comments-and-strings)?  Etc. etc.
> 
> I don't think that would be an issue. At the moment, the primary place
> to use these kind of special environments is a Unix shell. If basic
> tools like coreutils weren't in the environment, the environment would
> already be useless for the user. And the only way to get some kind of
> useless environment like that would be to explicitly configure it; I'm
> inclined to call that user error. Also: These special environments
> typically just prepend new directories to PATH and other vars,
> "inheriting" the binaries that were in the user's pre-existing
> environment, and just overriding some, so in the typical case things
> will certainly work fine.
> 
> Also note: If a binary from outside some project-specific environment is
> run within that environment, it might break. (Maybe you preload some
> crazy library within the project-specific environment, and have a set of
> project-specific binaries that know how to cope with that.)

See, the above 2 paragraphs contradict each other.  The second one is
precisely the kind of breakage I had in mind and feared of, and I see
now that we are in violent agreement regarding such a possibility.

Prepending directories to PATH doesn't solve these problems.  E.g., if
the prepended directory holds a version of gzip that is "broken" in
the above-mentioned meaning in the environment of a project, then
Emacs will be unable to visit gzip-compressed files, such as Info
manuals and its own Lisp sources.

I think we need to avoid this danger.

> So if we don't modify exec-path to be project-specific, then anything
> that wants to run a process inside the project-specific environment
> would need to be explicitly modified to search the project-specific
> path, to avoid running outside binaries inside the special
> environment.

I think the suggestion to define a series of variables, which, if
non-nil, will override the exec-path search by the relevant
primitives, avoids this issue, because these variables will be handled
on the infrastructure level.

> > Once again, why not use locate-file?  CEDET and EDE already do, and I
> > assume for good reasons.
> 
> Yes, a new program that wants to search per-environment search paths
> could use locate-file. But I still hope for not needing to modify things
> to be environment-aware.

We cannot avoid some modifications anyway.  You are talking about
changing Emacs on a very low and delicate level.

> > More generally, why would a project want to modify exec-path? to find
> > which programs?  Is it only the compiler/interpreter of the
> > programming language used by the project, or something else as well,
> > and why?  E.g., I don't really understand your example with browse-url
> > -- why would I want to change a browser as function of the project I'm
> > working on?
> [...]
> maybe if you're developing a browser, you'd want browse-url to pick
> up the version compiled in the project-specific environment when
> you're working on it.

browse-url already has browse-url-*-program and
browse-url-default-browser variables that should be enough to cater to
this use case.  A project can simply customize their values, and make
them buffer-local if needed.

> In general I think it's entirely reasonable to want to be able to run
> project-specific version of developer tools. The compiler/interpreter is
> the most obvious project-specific program, but there are benefits to
> supporting running every developer tool inside the project-specific
> environment.

But exec-path is not just for development tools.  It's for _any_
program Emacs might need to run.  Thus changing it has an effect that
is much more wide and prominent.

> Here are three benefits that I see for running everything within the
> project-specific environment by default:
> - This works identically (and therefore compatibly) to the Unix shell
> inside a special environment.

Actually, many development environments are configured by pointing at
specific absolute file names of the tools, such that any changes in
PATH don't affect them.

> - Any other project-specific developer tools that we don't know about or
> don't yet exist, will be automatically supported.
> - And most importantly: all the myriad programming modes for Emacs with
> their many custom methods for running their compiler/interpreter, will
> automatically support running their compilers/interpreters in an
> environment-aware way.

I think the downsides of this are too serious to ignore.  Like this
one, for example:

> However I admit that if the user wants to run a development program from
> outside the project-specific environment (or even a development program
> from another environment) it could become a little more tricky...

More generally, running _any_ program that doesn't belong to the
environment might subtly break.

> And the conceptually easiest way is still just updating Elisp commands
> (such as compile or shell-command) one by one to be environment-aware.

The challenge is to make changes to the infrastructure that cover the
80% of use cases in environment-aware development, without making the
cure worse than the disease.



  reply	other threads:[~2016-07-25 17:04 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14 21:36 Managing environments (Python venv, guix environment, etc.) sbaugh
2016-07-15 16:26 ` Stefan Monnier
2016-07-17 22:41   ` sbaugh
2016-07-18 10:15     ` Andreas Röhler
2016-07-18 14:46     ` Stefan Monnier
2016-07-18 19:13       ` sbaugh
2016-07-19 13:39         ` Stefan Monnier
2016-07-24  3:35         ` Dmitry Gutov
2016-07-24  8:25           ` sbaugh
2016-07-24 23:08             ` Dmitry Gutov
2016-07-21  0:32       ` sbaugh
2016-07-22 20:19         ` Stefan Monnier
2016-07-23  7:10           ` Eli Zaretskii
2016-07-24  3:26             ` Dmitry Gutov
2016-07-24  8:25               ` sbaugh
2016-07-24 14:28                 ` Eli Zaretskii
2016-07-24 17:45                   ` sbaugh
2016-07-24 17:58                     ` Eli Zaretskii
2016-07-24 19:05                       ` Spencer Baugh
2016-07-24 19:36                         ` Eli Zaretskii
2016-07-25  4:50                           ` sbaugh
2016-07-25 17:04                             ` Eli Zaretskii [this message]
2016-07-28  0:47                               ` sbaugh
2016-07-24 23:04                 ` Dmitry Gutov
2016-07-25  2:37                   ` Eli Zaretskii
2016-07-25  5:01                     ` sbaugh
2016-07-25 17:06                       ` Eli Zaretskii
2016-07-25  7:07                   ` Michael Albinus
2016-07-25 12:49                     ` Dmitry Gutov
2016-07-25 13:03                       ` Michael Albinus
2016-07-25 13:06                         ` Dmitry Gutov
2016-07-25 13:41                         ` Stefan Monnier
2016-07-28  0:02                         ` sbaugh
2016-07-28  9:34                           ` Michael Albinus
2016-07-28 14:42                           ` Eli Zaretskii
2016-07-29 17:59                             ` sbaugh
2016-07-29 18:59                               ` Eli Zaretskii
2016-07-29 19:20                                 ` Stefan Monnier
2016-07-30  6:57                                   ` Eli Zaretskii
2016-07-30 14:42                                     ` Stefan Monnier
2016-07-30 15:56                                       ` Eli Zaretskii
2016-07-29 20:57                                 ` sbaugh
2016-07-30  7:34                                   ` Eli Zaretskii
2016-07-30 13:30                                     ` sbaugh
2016-07-30 16:17                                       ` Eli Zaretskii
2016-07-30 11:24                                   ` Michael Albinus
2016-07-29 18:42                           ` Stefan Monnier
2016-07-29 19:03                             ` Eli Zaretskii
2016-07-26  2:36                   ` Stefan Monnier
2016-07-24 14:24               ` Eli Zaretskii
2016-07-25  0:05                 ` Dmitry Gutov
2016-07-25 17:00                   ` Eli Zaretskii
2016-07-26  2:08                     ` Dmitry Gutov
2016-07-26  3:06                       ` Stefan Monnier
2016-07-26 10:45                         ` Michael Albinus
2016-07-26 12:46                           ` Stefan Monnier
2016-07-26 14:49                       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2016-07-28 10:01 Spencer Baugh
     [not found] <87shuuvzz6.fsf@totally-fudged-out-message-id>
2016-07-28 10:08 ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83lh0ptzrd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=sbaugh@catern.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.