[REGRESSION] bzr 1.17 does not use _knit_load_data compiled extension

[Martin Pool]

2009/7/30 John Arbash Meinel <john at arbash-meinel.com>:
>> There have been several cases where people have not been using the
>> extensions or not been using the correct extensions and it causes
>> confusing behaviour, or it causes them to see bzr as being slower than
>> it can be.
>>
>
> so I've written tests in the past that if X is available, then it is
> used. And then if X is not available, we get a MissingFeature.

Right, and modulo your other point I think this is entirely
appropriate for code that tests the extensions or things that depend
on them.  I was talking more about how we handle the import of them
from the non-test code: we absorb the ImportError and that's always a
bit risky.

> The issue is that PQM doesn't care about MissingFeature, partially
> because it is mixed with PlatformDoesNotSupport.

Yes, I have some long-pending work to separate these out more cleanly
- I think there is a description in the hacking guide of how it's
meant to work.  Without rehashing all of that here, you do want to
distinguish "I've tested everything I possibly could on this OS" from
"I couldn't test some things because you don't have the library
dependencies" from "I couldn't test some things because you didn't run
make, you goose" from "stuff really failed".  I think normally PQM
should check the extensions were built, and fail if not.

Also the missing-feature warnings are tending to become so long that
people glaze over them, and it might be better to just say something
like

  Warning: tests skipped because of missing extensions: readdir, dirstate, .....

on one line.

>
> I'm fine with having an explicit warning since I think we've evolved to
> depend on these things. I'm concerned with:
>
> 1) Getting 10 warnings on every run when you don't compile any
> extensions. It would be nice to have them aggregated. One possibility
> would be to collect info about missing things, and report them as part
> of the exit code. This also has the advantage of not intermixing signal
> and noise. You get all the noise at once.

Good idea.  It may mean you don't get any message in something like
'bzr serve' that doesn't terminate though, but perhaps covering the
main case is enough.

Alternatively we can give just one warning naming at least one
extension that's missing: or just say extensions are missing and
mutter the details of them.

> 2) I think people would rather do "echo ignore_missing_extension=True"
>>> ~/.bazaar/bazaar.conf, rather than setting an env var. Our config
> code is unfortunate right now, because every check would need to re-read
> the config file.

I was going to put it in there, but had the conceptual problem that we
start trying to import these things before we have enough
infrastructure up to read the config file.  If we check it atexit it
may be ok.

Hm, actually not because you may already be in Python's sky-is-falling
finalization state where you can't load new code?

-- 
Martin <http://launchpad.net/~mbp/>