In cases like bug 405653 the compiled extensions were not being loaded properly. This can cause a large performance regression but it may not be obvious that performance is low because of an easily fixed problem.
We want to keep the ability to run bzr using only Python implementations because: being able to cross-test against the Python implementations may be useful for debugging, and because it's useful to run bzr in environments where it's not possible to build extensions. Both of these are usual situations and people should know what they're getting in to.
We'd like a red flag when either:
* someone commits a change (eg to pqm) that causes extensions not to be loaded when they should be
* a problem in the source, in packaging, or installations causes extensions not to be loaded at run time when they should be
I'm suggesting these are different aspects of the bug because it's quite possible to have either failures in the source that mean it doesn't correctly attempt to load the extension even if it's built, or possible to have problems in the build scripts, installation or packaging that may mean users experience this problem even if there's no problem in the upstream tree.
At the moment our protection against this is comprised of: per-implementation tests that can raise dependency not present results; and a check in setup.py that causes it to fail unless the extensions are built.
The problem as I see it is that if you manage, in whatever way, to get a copy of bzr that doesn't load its extensions, it will silently fall back on every run.
If you really want just the python code obviously this is desirable but I think that's the abnormal case.
How about: we will always give a warning (or even error) if failing to load them, unless an environment variable or config setting is given to turn it off?