fix: expose the mocked Juju environment variables via os.environ again

[tonyandrewmeyer]

Rather than only put JUJU_VERSION into os.environ, copy the entire contents of the mock Juju environment variables (and after the run, put the environment dictionary back to the same state it was originally).

In general, we feel that charms should be using ops to access this information, rather than going directly to the raw environment variable, but this was too large a change to make in a refactoring bugfix release, and should wait for an 8.x release (and also ensuring that there are reasonable ways to get everything from ops - for example, the event name is perhaps too tricky to get globally right now).

Fixes #1572

[benhoyt]

Code change looks good to me -- thanks. Two questions:

1. Have you tested that this fixes the broken charm tests mentioned in ops-testing should expose the mocked JUJU_ environment variables in os.environ #1572? If not, could we double-check that and note it here.
2. Do you think we should do a point release of ops/ops-scenario after this is merged?

[tonyandrewmeyer]

1. Have you tested that this fixes the broken charm tests mentioned in ops-testing should expose the mocked JUJU_ environment variables in os.environ #1572?

Yes, although it also needs:

--- a/tests/scenario/test_charm_tracing.py
+++ b/tests/scenario/test_charm_tracing.py
@@ -29,7 +29,7 @@ from charms.tempo_coordinator_k8s.v0.tracing import (
 from ops import EventBase, EventSource, Framework
 from ops.charm import CharmBase, CharmEvents
 from scenario import Context, Relation, State
-from scenario.runtime import UncaughtCharmError
+from scenario.errors import UncaughtCharmError
 
 logger = logging.getLogger(__name__)
 

The only other charm that I have locally that needs this is tempo-k8s-operator (which is archived). We could re-export things from _runtime to runtime but I feel like that would somewhat negate the point of moving everything to the private module anyway. You can get UncaughtCharmError from scenario.errors in 7.0.0, the recent change is not being able to also get it from scenario.runtime. My preference here would be to keep things as they are.

2. Do you think we should do a point release of ops/ops-scenario after this is merged?

I feel this ties into the general "do we wait for the end of the month" discussion. This doesn't seem as urgent as breaking deferring in some cases - it's only testing, and it's only this one lib as far as we know - but I'm also not opposed to releasing fixes as we get to them.

[james-garner-canonical]

Suggested change

	for key, value in os.environ.copy().items():
	if key in previous_env:
	os.environ[key] = value
	else:
	del os.environ[key]
	for key, value in previous_env.items():
	if key not in os.environ:
	os.environ[key] = value
	for key, value in previous_env.items():
	os.environ[key] = value
	for key in tuple(os.environ):
	if key not in previous_env:
	del os.environ[key]

The other way round works too

Suggested change

	for key, value in os.environ.copy().items():
	if key in previous_env:
	os.environ[key] = value
	else:
	del os.environ[key]
	for key, value in previous_env.items():
	if key not in os.environ:
	os.environ[key] = value
	for key in tuple(os.environ):
	if key not in previous_env:
	del os.environ[key]
	for key, value in previous_env.items():
	os.environ[key] = value

[james-garner-canonical]

Oh hold up, how about this:

Suggested change

	for key, value in os.environ.copy().items():
	if key in previous_env:
	os.environ[key] = value
	else:
	del os.environ[key]
	for key, value in previous_env.items():
	if key not in os.environ:
	os.environ[key] = value
	for key in tuple(os.environ):
	if key not in previous_env:
	del os.environ[key]
	os.environ.update(previous_env)