[MERGE] Better warnings when pyrex is not available

[John Arbash Meinel]

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

Martin Pool wrote:
> On 7/16/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> 
>> Since have finally merged our first Pyrex extension into bzr, we have now
>> started running into the user difficulties.
>>
>> Erik de Castro Lopo was having difficulties running 'python setup.py
>> install'
>> because he didn't have Pyrex installed, and we aren't versioning the
>> .c files.
>>
>> The attached patch changes the 'make' step in the following ways:
>>
>> 1) Pyrex is available has no changes:
>> % make
>> building extension modules.
>> python setup.py build_ext -i
>> running build_ext
>> building 'bzrlib._knit_load_data_c' extension
>> ... (gcc lines)
>>
>>
>> 2) Pyrex not available, but the .c files are present (such as in a
>> release):
>> building extension modules.
>> python setup.py build_ext -i
>>
>> The python package 'Pyrex' is not available. If the .c files are
>> available,
>> they will be built, but modifying the .pyx files will not rebuild them.
>>
>> running build_ext
>> building 'bzrlib._knit_load_data_c' extension
>> ... (gcc lines)
>>
>> 3) Pyrex not available, and .c files not present (bzr.dev):
>> building extension modules.
>> python setup.py build_ext -i
>>
>> The python package 'Pyrex' is not available. If the .c files are
>> available,
>> they will be built, but modifying the .pyx files will not rebuild them.
>>
>> C extension(s) not found:
>>    bzrlib/_knit_load_data_c.c
>> The python versions will be used instead.
>>
>> running build_ext
>>
>> I hope this makes it a little more obvious what people can do to fix the
>> situation, as well as not interrupting them if they don't want them.
> 
> +1 to the patch.  BB missed it for some reasons.

Thanks.

> 
>> Also, do you think we should be adding a 'trace.mutter()' comment
>> during the
>> try/import section (when trying to load a compiled extension?). We
>> have them
>> for other missing dependencies like cElementTree and pycurl. Thoughts?
> 
> I think so.  Maybe we should make it more prominent than that?  End
> users probably won't ever see them.  But showing it on every
> invocation is too much.

Yeah, that is the current problem. We either have 'warn all the time' or
'mutter to the log file'.

The alternatives aren't great either, though. 'warn 1/day', 'warn once', 'warn
1/<interval>'. Warning 1/invocation when it would actually be used is okay
(consider the upgrade warnings versus the bzrtools is out of date warnings. I
generally find the 'upgrade' ones useful to remind me about this tree, bzrtools
may be better now, but it used to go out of date on every release, which was a
bit annoying).


> 
> Also, I think you mentioned that pycurl is probably not really a good
> deal now urllib is so much better?
> 

I personally think that urllib should be the default. My only doubt is that it
doesn't validate certificates in any way. If it did, I would be 100% behind
making urllib the default.

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

iD8DBQFGm7ZVJdeBCYSNAAMRAjqFAJ0aU0XuKxr/AjoHSeJFg8VWMH6ggQCaAiKt
Ma15rLH1A+zlVAjC0ogCIGM=
=GsLM
-----END PGP SIGNATURE-----