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:
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
@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
