ELPA package submission: buffer-env

ELPA package submission: buffer-env

[Augusto Stoffel]

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

Re: ELPA package submission: buffer-env

[Stefan Monnier]

> 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

Re: ELPA package submission: buffer-env

[Augusto Stoffel]

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.

Re: ELPA package submission: buffer-env

[Stefan Monnier]

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