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,...'.

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?

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.

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.

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.

Logged In: YES 
user_id=593130

See item 964703 for further information and then decide.

Logged In: YES 
user_id=21627

Moved to RFE.

Hallvard, do you still consider this a live issue?

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.

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.)

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.

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.)

Yes, this could be reopened with a patch. Someone else would have to judge its usefulness and acceptability. So no guarantees.