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.
next prev parent 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.