Deprecating harness_extensions.evt_sequences

For those who know, evt_sequences was a prototype of a charm lib (never got past 0.1) for doing what later became Scenario. It used ops.testing.Harness as backend and has had it coming a long time already.


This is not just an announcement, also food for thought: as far as I’m aware of, there is no ‘standard’ process in place for deprecating charm libs. So here’s how I did it, maybe we can have a discussion about whether this makes sense or not.

As of two seconds ago (time of writing), if you run:

charmcraft fetch-lib charms.harness_extensions.v0.evt_sequences

you will get:

all the code is gone, so you’ll only get the deprecation warning and if you’re hoping to just upgrade a dependency, that won’t work out well.

Is that too harsh?

1 Like

Hi @ppasotti

In many projects the “standard” way to deprecate classes, methods, functions, etc is by logging warning messages saying something like:

DEPRECATION NOTICE: In version x.y.z this class/method/function will be deprecated. 

and when the project reaches that version, the code is finally removed.

In our case we never went further 0.1… so I think removing the code is harmless… Any way I think this is a good opportunity to start modelling a process to do that.

Thanks Jose, good thinking! I wasn’t sure how standard this was, because I’m deprecating a whole project, not just a class/method/function. It’s more than deprecating perhaps, it’s sunsetting :city_sunset:

1 Like

@roadmr I was also wondering, is there a way to ‘unregister’ a charm lib, or otherwise erase it from existence, or signal somehow to those trying to charmcraft fetch-lib the library, that it has been moved, removed, deprecated, etc…?

There’s no way to do so easily. If there’s a need to delete a library because otherwise the world will end, we can do it but it involves ugly database manipulation.

What you can do is just put a raise SystemExit("lib deprecated") in the library and upload a new version :slight_smile:

  • Daniel
1 Like