[MERGE] make plugins use the right suffixes

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> On Fri, 2006-07-14 at 15:40 -0500, John Arbash Meinel wrote:
>> I don't have any tests for it, because it would involve spawning bzr
>> as
>> a separate process, and running it with either 'python -O' or
>> 'python'.
>> Which is possible to do, but doesn't seem worthy for this change.
> 
> Errr, why would it? Surely just looking at the current setting, and at
> the calculated prefixes (break the calculation into a function) is
> enough.

The bug we had was that we would try to import 'foo.pyo' when we were
running in normal mode. Which python doesn't actually let you do. (It
also won't load .pyc files in -O mode).

Here is a test:

% echo "print 'import foo'" > foo.py
% python -c 'import foo'
import foo
% python -O -c 'import foo'
import foo
% ls
foo.py  foo.pyc  foo.pyo
% rm foo.py
% mv foo.pyc xxfoo.pyc
% ls
foo.pyo xxfoo.pyc
% python -c 'import foo'
Traceback (most recent call last):
  File "<string>", line 1, in ?
ImportError: No module named foo
% mv xxfoo.pyc foo.pyc; mv foo.pyo xxfoo.pyo
% ls
foo.pyc  xxfoo.pyo
% python -O -c 'import foo'
Traceback (most recent call last):
  File "<string>", line 1, in ?
ImportError: No module named foo


> 
> To make it testable, rather than the function being magic, you could
> give it the O mode to import in, then you can call it without restarting
> python, and the only room for error is if the caller of the routine
> passes in the right global state variable.
> 
> Anyhow, will read the patch Monday.
> 
> Rob
> 

I don't really understand what you mean by the 'right global state
variable'. I'm not sure which function you believe to be magic.
Perhaps the one that generates the __init__.py* valid names.
I certainly could break that up into a separate function, and then test
that it returns what I expect it to, based on the current
imp.get_suffixes() value.

What I'm trying to test is that if we are running without -O, we will
still load a plugin if it is only a .pyc file, and we *won't* load a
plugin if it is a .pyo (and we won't *try* to, either).
And if we are running with -O, then the situation is reversed.

I wanted to support .pyc and .pyo, so we can have "proprietary" plugins,
where they don't want to release the source code. At the time, I thought
python would load either one if it was available. I have since found out
that it will only load one that matches its current state.
(So installers should *always* compile to both .pyc and .pyo, since
otherwise running python -O, is foolish, as it has to recompile all the
modules on the fly, every time.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuQqUJdeBCYSNAAMRAtoyAJ4w/F4dfjCb8O/2HXW6T6GVnXr/6wCdGJvE
NO3d8u1YVlBIgVNbcMougjI=
=kG2r
-----END PGP SIGNATURE-----