Why the choice of Python 3? I probably wouldn’t use any tool like this that doesn’t solely depend on /bin/sh (or can’t be executed via /rescue/sh). The reason being is that if my boot environment is so screwed up that non-base applications (like python) don’t work, yet statically-compiled applications in base (like /rescue/sh) do work, I can’t use zedenv but I can use beadm. My main use case for boot environments is for installing updates and sometimes updates go haywire. I have hit, and am 100% sure I will hit, instances where my environment is so screwed up, only /rescue will rescue me.
I wanted to build something that’s easily maintainable, and while sh is great, it’s not a programming language. I realize that complex applications can be created with sh, but over time they can become unwieldy. I think they are great for small scripts like starting up services in rc.d, and scripting things quickly, but when I want to build something that can be used or long-term, I would rather use a programming language.
Part of the point of boot environments, you’re so that you don’t have to enter /rescue. You create a boot environment for the new update, do the update there, and if things go haywire you boot into the old boot environment. At that point, you can mount your broken boot environment, do some surgery, and once fixed you can reboot into it.
If things are so haywire that all of your boot environments aren’t working, and you have to use /rescue, it’s probably not related to boot environments. If it is, you can always use zfs to fix your problem.
FreeBSD had a Google Summer of Code project for improving its boot environment management. I’m not sure about its status though.