* ELPA package submission: buffer-env
@ 2022-02-28 18:53 Augusto Stoffel
2022-02-28 19:40 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Augusto Stoffel @ 2022-02-28 18:53 UTC (permalink / raw)
To: emacs-devel
I would like to propose the following package for inclusion in ELPA:
https://github.com/astoff/buffer-env
The immediate purpose of the package (for me) is to deal with Python
virtualenvs. But it should be useful when working on any project with
dependencies that are not globally installed.
Some time ago I started a thread on this list explaining why I thought
Emacs should have better support for setting the process environment per
project / buffer locally [1]. But it's not clear there's a case for a
built-in facility; and while this package is not extremely beautiful it
solves the matter satisfactorily. So after quite some incubation time I
decided it's worth sharing.
I should also note that this package is a knock-off of the "envrc"
package from MELPA [2]. It's surely a fine package but it requires on
the direnv program, which to me seems like an unnecessary dependency.
[1]: https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg01376.html
[2]: https://github.com/purcell/envrc
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ELPA package submission: buffer-env
2022-02-28 18:53 ELPA package submission: buffer-env Augusto Stoffel
@ 2022-02-28 19:40 ` Stefan Monnier
2022-02-28 19:54 ` Augusto Stoffel
0 siblings, 1 reply; 4+ messages in thread
From: Stefan Monnier @ 2022-02-28 19:40 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
> I would like to propose the following package for inclusion in ELPA:
>
> https://github.com/astoff/buffer-env
>
> The immediate purpose of the package (for me) is to deal with Python
> virtualenvs. But it should be useful when working on any project with
> dependencies that are not globally installed.
>
> Some time ago I started a thread on this list explaining why I thought
> Emacs should have better support for setting the process environment per
> project / buffer locally [1]. But it's not clear there's a case for a
> built-in facility; and while this package is not extremely beautiful it
> solves the matter satisfactorily. So after quite some incubation time I
> decided it's worth sharing.
That sounds useful (and I think we should improve Emacs's core to better
support such features; we already have some ad-hoc
frame-local-environment support and it would be good to make that less
ad-hoc).
The default value for `buffer-env-command` is a gaping security hole, tho.
Any hope we can make this a bit less dangerous?
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ELPA package submission: buffer-env
2022-02-28 19:40 ` Stefan Monnier
@ 2022-02-28 19:54 ` Augusto Stoffel
2022-02-28 19:58 ` Stefan Monnier
0 siblings, 1 reply; 4+ messages in thread
From: Augusto Stoffel @ 2022-02-28 19:54 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
On Mon, 28 Feb 2022 at 14:40, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> The default value for `buffer-env-command` is a gaping security hole, tho.
> Any hope we can make this a bit less dangerous?
I think it's already made sufficiently tame: before running any given
version of an .envrc script, you have to explicitly say yes. Then a
hash of the script contents is saved in a custom variable, so the second
time you run the same script you don't need to confirm.
I copied that idea from the direnv program, so I want to believe that
any security holes should be due to bad implementation rather than a bad
concept.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ELPA package submission: buffer-env
2022-02-28 19:54 ` Augusto Stoffel
@ 2022-02-28 19:58 ` Stefan Monnier
0 siblings, 0 replies; 4+ messages in thread
From: Stefan Monnier @ 2022-02-28 19:58 UTC (permalink / raw)
To: Augusto Stoffel; +Cc: emacs-devel
Augusto Stoffel [2022-02-28 20:54:17] wrote:
> On Mon, 28 Feb 2022 at 14:40, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> The default value for `buffer-env-command` is a gaping security hole, tho.
>> Any hope we can make this a bit less dangerous?
> I think it's already made sufficiently tame: before running any given
> version of an .envrc script, you have to explicitly say yes. Then a
> hash of the script contents is saved in a custom variable, so the second
> time you run the same script you don't need to confirm.
Ah, sorry, I missed this detail. Good, thanks,
Stefan
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-02-28 19:58 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-02-28 18:53 ELPA package submission: buffer-env Augusto Stoffel
2022-02-28 19:40 ` Stefan Monnier
2022-02-28 19:54 ` Augusto Stoffel
2022-02-28 19:58 ` Stefan Monnier
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.