| msg54158 - (view) |
Author: Hallvard B Furuseth (hfuru) |
Date: 2004-05-25 19:07 |
| I'd like to be able to configure Python so that Configure or Make will fail if a particular feature is unavailable. Currently I'm concerned with SSL, which just gets a warning from Make: building '_ssl' extension *** WARNING: renaming "_ssl" since importing it failed: ld.so.1: ./python: fatal: libssl.so.0.9.8: open failed: No such file or directory Since that's buried in a lot of Make output, it's easy to miss. Besides, for semi-automatic builds it's in any case good to get a non-success exit status from the build process. Looking at the Make output, I see the bz2 extension is another example where this might be useful. Maybe the option would simply be '--enable-ssl', unless you want that to merely try to build with ssl. Or '--require=ssl,bz2,...'. |
|
|
| msg54159 - (view) |
Author: Terry J. Reedy (terry.reedy) *  |
Date: 2004-06-01 17:58 |
| Logged In: YES user_id=593130 Are you claiming that there is an actual bug, or is this merely an RFE (Request For Enhancement) item? |
|
|
| msg54160 - (view) |
Author: Hallvard B Furuseth (hfuru) |
Date: 2004-06-01 18:13 |
| Logged In: YES user_id=726647 I marked it with Group: Feature Request. Not a bug, but a quality of implementation issue. It seemed more proper here than as a PEP. |
|
|
| msg54161 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2004-06-02 02:07 |
| Logged In: YES user_id=593130 Yes, this is not a PEP item. I didn't notice Feature Reqest since it is redundant vis a vis the separate RFE list. |
|
|
| msg54162 - (view) |
Author: Hallvard B Furuseth (hfuru) |
Date: 2004-06-02 11:56 |
| Logged In: YES user_id=726647 Ah, so that's what RFE means. You could rename that to 'Enhancement Requests'. Anyway, QoI issues tend to resemble bug issues more than enhancement issues, so '"bug" of type feature request' looks good to me. Though I'll resubmit as RFE if you ask. |
|
|
| msg54163 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2004-06-04 21:35 |
| Logged In: YES user_id=593130 See item 964703 for further information and then decide. |
|
|
| msg54164 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-06-21 05:49 |
| Logged In: YES user_id=21627 Moved to RFE. |
|
|
| msg82086 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2009-02-14 16:39 |
| Hallvard, do you still consider this a live issue? |
|
|
| msg88234 - (view) |
Author: Björn Lindqvist (bjourne) |
Date: 2009-05-23 12:58 |
| I'm not Hallvard but I'd also appreciate this feature. I think it is quite important to have for automated build systems; Python seem to build correctly but then down the line some other package fails because the bz2 module is not available. IMHO it is wrong that you _can_ build python without libbz2 (for example) because what you get is a broken standard library. It is not mentioned anywhere in the documentation that bz2 is an optional module. I think terminating the build at the configure step if libbz2 is not found would be correct. Otherwise maybe the standard --with configure options could be used for this. E.g. ./configure --with-bz2 --with-ssl etc. |
|
|
| msg120408 - (view) |
Author: Hallvard B Furuseth (hfuru) |
Date: 2010-11-04 14:21 |
| Once upon a time, Terry J. Reedy wrote: > Hallvard, do you still consider this a live issue? If this general behavior remains, yes. It's been a while since I had a computer without these libraries to test it on. (Which is why I punted and then forgot to answer, sorry.) |
|
|
| msg120429 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-11-04 19:44 |
| I am closing this as some combination of wrong, inapplicable, out-of-date, and postponed. 1. In 3.1, ssl *is* documented as optional in the sense of dependent on an external library. "This module uses the OpenSSL library. It is available on all modern ... platforms, as long as OpenSSL is installed on that platform." For bz2, there is "This module provides a comprehensive interface for the bz2 compression library." If the library is not there, then the module obviously cannot function. Tkinter depends on tcl/tT being installed. I believe some crypto modules also require possibly absent libraries. (The PSF/Löwis Windows installer nicely provides all.) If someone wants to review the docs for all such dependencies (and perhaps whatever build docs or help strings or comments there are) and propose doc revision, that could be a separate issue. 2. I think the current default build process is right for most users. 3. Except for the PSF provided binaries, building is ultimately out of our hands. Distributions do what they do. I presume individual persons and organizations can patch the default build files to be stricter if they wish. If they cannot, neither can we ;-). 4. This seems to have become pretty much a non-issue. The OP says he has no further concrete interest because "It's been a while since I had a computer without these libraries...". I am suspecting this is pretty much true for everyone who might otherwise care enough to provide a patch. |
|
|
| msg120867 - (view) |
Author: Hallvard B Furuseth (hfuru) |
Date: 2010-11-09 14:18 |
| Just for the record, I think you read this a bit too fast before closing: Terry J. Reedy writes: > I am closing this as some combination of wrong, inapplicable, > out-of-date, and postponed. > > 1. (...) For bz2, there is "This module provides a > comprehensive interface for the bz2 compression library." If the library > is not there, then the module obviously cannot function. The point of the request was to move that error from runtime to compile time. As a configuration option, not by default, since as you say: > 2. I think the current default build process is right for most users. Indeed. > 4. This seems to have become pretty much a non-issue. The OP says he has > no further concrete interest because "It's been a while since I had a > computer without these libraries...". I am suspecting this is pretty > much true for everyone who might otherwise care enough to provide a > patch. Half right - actually I _would_ still prefer that bit of safety, but OTOH I probably won't be providing a patch anytime soon. (Still, I can always reopen the issue if I do write one.) |
|
|
| msg120870 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-11-09 15:39 |
| Yes, this could be reopened with a patch. Someone else would have to judge its usefulness and acceptability. So no guarantees. |
|
|