[MERGE] Better warnings when pyrex is not available

[John Arbash Meinel]

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

James Westby wrote:
> On (16/07/07 13:10), John Arbash Meinel wrote:
>> That sounds like a packaging issue. Pyrex should depend on python-dev if it is
>> required to work.
> 
> On Debian python-pyrex Recommends: python-all-dev.
> 
> This is the correct dependency. pyrex itself doesn't need the header
> files to generate the C, but gcc needs them to compile it.
> 
> The definition of Recommends: is that only unusual requirements would
> mean that it is not installed. However this is subverted by the fact
> that Recommends aren't installed by default with many tools. This has
> meant that Depends: is more often used for this sort of thing, lessening
> the impetus to fix it and make Recommends what they are defined to be.
> 
> Whether this means that pyrex should depend on python-all-dev is an open
> question, and one that we don't actually control. We could file a
> wishlist bug against python-pyrex to change the dependency to get the
> maintainer's opinion.

Considering all of that, I think I'd rather just let the 'python setup.py
build' fail, and let people sort it out.

This isn't part of the test suite, it is just a regular build dependency issue.

I suppose we could have a meta-package of 'bzr-dev' which would depend on all
the things that you need to build bzr now.

I know there was also discussion a while ago (I think by Robert) about
splitting the bzr package into a 'bzrlib', since it is a bit more 'correct' for
3rd-party dependencies like Olive.

> 
>> Do you know a way to detect if python-dev is installed for your machine?
>>
>> Preferably something along the lines of 'import foo', rather than
>> 'os.subsystem("apt-cache search python-dev")'
>>
> 
> Looking at the file list in python2.4-dev there is no file included in
> the default PYTHONPATH. This means that os.system is probably the best
> you can do, though there would probably be more efficient commands that
> that for getting the information. (Though apt-cache isn't the tool here,
> dpkg -l is for whether the package is installed, but just looking for
> the files, or trying a test compile as autotools would is probably
> better for those that don't use packages and those not on Debian based
> systems.)
> 
> Thanks,
> 
> James
> 

Sure, I wasn't recommending 'apt-cache' as a real option. And it would be very
site-dependent. (is it python-all-dev or python-dev or python2.4-all-dev, or is
it 'rpm -q' instead of 'dpkg -l', or fink or darwin ports, or ..).

If it was a python module we could inspect, then it might make sense to do it
ourselves. I don't think we can reasonably handle the large permutations of
possible packaging systems. Especially considering the package name can easily
change over time even if the system itself is fixed.

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

iD8DBQFGm8+WJdeBCYSNAAMRArJgAKCmqGmIDpYE099wCyJKu2k7AsFR7ACgllw9
Rg6hypoNXYutFUHFlMRA/vs=
=TRKt
-----END PGP SIGNATURE-----