Closed tonyandrewmeyer closed 2 months ago
Thanks, @tonyandrewmeyer. Side note: I think one would usually write import ops.testing as testing
as from ops import testing
, right?
@PietroPasotti I realize you might disagree with this direction. Happy to hear your feedback and come to consensus (open to a voice discussion about this -- or anything else -- if needed).
Side note: I think one would usually write
import ops.testing as testing
asfrom ops import testing
, right?
Yes one would. It's actually slightly slower (looking with dis, I assume because the latter builds a tuple), but I just generally don't like the aesthetics of mixing "import x" and "from x import y", although it's certainly valid in this case. I can adjust the PR description if you prefer (and I would almost certainly write "from ops import testing" in docs, going for convention over personal preference).
@PietroPasotti I realize you might disagree with this direction. Happy to hear your feedback and come to consensus (open to a voice discussion about this -- or anything else -- if needed).
+1 (but "realise" :wink: ).
Haha, you have to reali(z|e) I'm an American Kiwi... :-)
Adds classes that match the ops status classes:
These are comparable with (both
==
andisinstance
) the ops classes, so this is a backwards compatible change (except for static checking), but the expectation is that instead of this code:you would write:
Or, in a future time when the Scenario objects live in
ops.testing
:In the same way that
__post_init__
converts ops status classes to Scenario ones, it will also convert opsPort
andStorage
objects, and the Scenario classes gain an__eq__
so they can be used more interchangeably with the ops objects. They don't inherit from the ops classes, becauseisinstance
seems unlikely to be useful in these cases, and that would bring in additional baggage.(I originally planned to remove
_EntityStatus
in favour of using ops.StatusBase by getting the ops status classes converted to dataclasses, but the @canonical/charm-tech team decided that it would provide a more consistent experience to have the Scenario state only contain Scenario objects (and plain Python ones), and no ops ones.)