TL;DR: if you need to run your charm integration tests across Juju versions from 2.9 through to 4.0, then (1) change your dependency from jubilant to jubilant-backports, and (2) change your imports from import jubilant to import jubilant_backports as jubilant, and you should be good to go.
If you’re new to Jubilant, read the announcement from earlier in the year - essentially, it’s a library that gives you a Pythonic API for Juju, so you can write your charm integration tests in the same way that you’d run CLI commands (but in Python).
If you’re new to jubilant-backports: Jubilant supports Juju 3.x and 4.0 (and is expected to support 4.x going forward). Some charms still provide support for Juju 2.9, and are therefore in a tricky situation where they can’t test against 2.9 with Jubilant, but can’t test against 4.0 with python-lib-juju. jubilant-backports solves this by providing the same API as Jubilant, but under the hood translating to Juju 2.9 CLI commands as necessary, and can parse responses from Juju 2.9 controllers, providing the same response classes as regular Jubilant.
Note that we suggest that you do import jubilant_backports as jubilant and then jubilant.Juju() (and so on) rather than import jubilant_backports and jubilant_backports.Juju(). Doing this means that when you’re able to drop Juju 2.9 support, you can change the dependency and the imports, and leave the rest of your test code unchanged.
Fast-forward to today: Charm Tech have just released jubilant-backports v1.4.0. This release should feel just like the previous one, except that if you were having to deal with classes from both jubilant and jubilant-backports, like pytest.raises(jubilant.TaskError, jubilant_backports.TaskError), those problems will have gone away.
Under the hood, this is a significant release:
- The code now lives in the
jubilant-backportsbranch of the official canonical/jubilant repository, rather than one of Tony’s (we’ll archive that soon). You can use the PyPI attestations to verify that you’re getting the official release. - We’re committing to maintaining this 2.9 support, with some caveats: we’re not intending to backport features from regular Jubilant (so you’ll have the Jubilant 1.4 feature set, but not anything newer), and once Canonical doesn’t have any production Juju 2.9 controllers, we’ll probably drop support (although the Jubilant security policy applies here). In the meantime, we’ll backport any security fixes and bug fixes, where applicable.
- We’ve switched from subclassing the Jubilant classes to a regular branch where the actual Jubilant code gains the 2.9 support. This should simplify use, such as the
pytest.raisescase mentioned above. There are a few status classes that may have empty fields depending on the Juju version (for example, blank “base” in Juju 2.9, blank “series” in Juju 3.x). - We’ve jumped the version from 1.0.0a1 to 1.4.0, so that it’s clearer that this gives the same feature set as
jubilant==1.4.0. We’ll keep the major and minor versions in sync (but, as noted above, don’t expect regular releases of that nature) but the bugfix numbers may increase independently.
With the project living in the canonical/jubilant repository now, please open issues there if you have any problems, or have other requests. We’re also in the Charm Development Matrix room if you need us!
Many thanks to the members of the charming Data teams for their feedback and encouragement for supporting Juju 2.9 with Jubilant. We hope you don’t need it for too long!