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 #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.

[benhoyt]

@tonyandrewmeyer Regarding whether we ship a new version, it's debatable, but I'd say this falls into "regression" territory and so we should ship a new (patch?) version.

The scenario.errors vs scenario.runtime change, I agree with you there. That would be an easy one for them to fix -- or just avoid -- in their tests (the environment one less so).

[tonyandrewmeyer]

@tonyandrewmeyer Regarding whether we ship a new version, it's debatable, but I'd say this falls into "regression" territory and so we should ship a new (patch?) version.

Ok. At the moment the only changes in main are docs so I can do this without needing to create a separate branch.