(Notmuch) environment is not isolated

[romanofski]

Describe the bug
I've come across a bug I've seen due to an alternative location of my notmuch config file. It is visible in the test, albeit touching perhaps on purebred-mua/hs-notmuch also.

Basically what happens is: if NOTMUCH_CONFIG is set in the environment pointing to a default notmuch location, running the tests which point to a different location using the purebred --database argument will cause separate threads using the location NOTMUCH_CONFIG is pointing to.

To Reproduce
Steps to reproduce the behavior:

1. Set NOTMUCH_CONFIG which points to database A. For me it's my main maildir I use every day.
2. Use the pull request which adds New mail indicator purebred#323 It creates a read connection to the notmuch database in a separate thread.
3. Run one of the tests and check the indicator how much new mail it shows. It should show the amount of new mail in your main inbox pointed at by NOTMUCH_CONFIG, not the test maildir.

Expected behavior
Create a tmux session with a minimal bash environment, so that variables already upon startup are not inherited.

Additional context
None

[frasertweedale]

Doesn't seem like a tasty-tmux bug to me; rather something in purebred or hs-notmuch. i.e. how we find out what notmuch database to open.

[romanofski]

Clarification: while the bug is very specific, we've got stung a few times with inherited environment variables. So the problem still stands that we want better support here. At least some more explicit control over what happens with the environment in a new tmux session.

[frasertweedale]

@romanofski might be inherited from the global environment of the the tmux server, and there's nothing we can do about it. I'd say we punt on this, or at most provide a helper function to (un)set user-specified envvars.

[romanofski]

Hm.. I've read something in the man page (see update-environment). Since we're controlling the session I'm sure we can do something about it.

[frasertweedale]

iirc update-environment just copies specified env vars from client environment to session environment when creating/attaching session. So unless the process environment of the test suite contains the correct vars... I mean for sure we can do something, but I'm not exactly clear what. If anything we should just run a clean login session of /bin/sh for every session?

[romanofski]

Yeah, a clean login shell sounds good! I haven't looked into it so you might be further down the track.