This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add option of non-zero exit status of setup.py when building of extensions has failed
Type: enhancement Stage:
Components: Build Versions: Python 3.6
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, eric.araujo, gpolo, loewis
Priority: normal Keywords: patch

Created on 2009-08-18 22:25 by Arfrever, last changed 2022-04-11 14:56 by admin.

Files
File name Uploaded Description Edit
python-non-zero_exit_status_on_failure.patch Arfrever, 2009-08-18 22:25 python-non-zero_exit_status_on_failure.patch review
Messages (21)
msg91719 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-18 22:25
sharedmods rule of Makefile calls setup.py which doesn't fail even
building of extensions has failed.
msg91725 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-19 06:25
It is deliberate that building Python succeeds even if building an
extension has failed.
msg91726 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-19 12:03
An option of `configure` could be added, whose enabling would change
this behavior.
msg91739 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-19 20:05
Why is it desirable to have such an option?
msg91740 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-08-19 20:09
This makes it more easily possible for automated systems to detect that
there was a problem with the build.

Checking an exit code is easy.  Grabbing and parsing stdout and stderr
is hard and fragile.
msg91743 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-19 20:26
> This makes it more easily possible for automated systems to detect that
> there was a problem with the build.

How do you define "problem" in this context? Why is it a problem if some
extension module did not get built? Perhaps it cannot build correctly
on this system. Is it, or is it not a problem that the module was not
built because header files were lacking that would be available, but
weren't installed on the build machine?
msg91744 - (view) Author: Jean-Paul Calderone (exarkun) * (Python committer) Date: 2009-08-19 20:27
If it's not a problem, then the invoker doesn't need to check the exit
code of setup.py.  Why are you resistant to exposing more information?
msg91745 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-08-19 20:34
> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py.

Suppose the _tkinter module failed to compile on a given system, how
would you know if this is a problem or not ? setup.py would return 1
because it couldn't be built, but the rest of Python were compiled
successfully.
msg91746 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-19 21:02
> If it's not a problem, then the invoker doesn't need to check the exit
> code of setup.py.  Why are you resistant to exposing more information?

Because I believe that the information that is being exposed in this
patch is confusing, and will trick people into believing things that
actually don't happen. When they then try to track down the problems,
they will (then rightly) complain that the implemented behavior is
incorrect.
msg91750 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-19 22:25
> When they then try to track down the problems, they will
> (then rightly) complain that the implemented behavior is
> incorrect.

setup.py could optionally fail immediately when building of an
extension has failed.
msg91753 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-19 22:35
>> When they then try to track down the problems, they will
>> (then rightly) complain that the implemented behavior is
>> incorrect.
> 
> setup.py could optionally fail immediately when building of an
> extension has failed.

What about skipped extensions (i.e. those where building them was
not even attempted?)

Why is it interesting to know that building was attempted, but failed?
msg91783 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-20 21:06
When building of an extension has failed due to external reasons (e.g.
headers from too old version of a Python dependency), user might prefer
to be forced to fix these reasons, than to have Python built without an
extension. If `make` doesn't fail, user might not notice the problem
during building of Python, but some time later during trying to import
some modules. Such behavior is also especially desired in distributions
(like Gentoo) in which packages are automatically built on users'
systems.

Maybe the option could be named --enable-strict-building-of-extensions?
msg91785 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-08-20 21:35
Wouldn't be more interesting to add an option where you tell exactly
which modules aren't expected to be compiled successfully ? If any
modules besides those specified are not built, then setup.py returns 1.

I, for instance, don't care if the _bsddb extension doesn't get built
but I do care that some others get compiled successfully.
msg91787 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-20 21:55
> Wouldn't be more interesting to add an option where you tell
> exactly which modules aren't expected to be compiled successfully ?
> If any modules besides those specified are not built, then setup.py
> returns 1.

It's good idea. The option of `configure` could be named
--enable-extensions=ext1,ext2,...

--enable-extensions=all could be also supported and it would mean that
all non-skipped extensions are requested.
msg91790 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-20 22:20
> When building of an extension has failed due to external reasons (e.g.
> headers from too old version of a Python dependency), user might prefer
> to be forced to fix these reasons, than to have Python built without an
> extension.

Ok - but your patch does not implement that. If the extension fails to
compile because the header files are not installed at all, even with
your patch, there is no error indication. So according to your
requirements, your patch is incorrect.
msg91791 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-20 22:22
>> Wouldn't be more interesting to add an option where you tell
>> exactly which modules aren't expected to be compiled successfully ?
>> If any modules besides those specified are not built, then setup.py
>> returns 1.
> 
> It's good idea. The option of `configure` could be named
> --enable-extensions=ext1,ext2,...
> 
> --enable-extensions=all could be also supported and it would mean that
> all non-skipped extensions are requested.

I also thought of such a solution, and could accept it.

However, it is really trivial to implement for anybody invoking an
automatic build of Python: after the build completes, do

python -c 'import ext1,ext2,...' 2>/dev/null

and check the return status - and voila, you know whether your required
modules were built successfully.
msg91792 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2009-08-20 22:30
> Ok - but your patch does not implement that. If the extension
> fails to compile because the header files are not installed at all,
> even with your patch, there is no error indication.

`make` will return error:

$ cat Makefile
x:
        false
all: x
$ make
false
make: *** [x] Error 1
$ 

Also note that my original patch was created before I slightly changed
my suggestion :) .
msg91801 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-21 05:35
> `make` will return error:

No it will not. I just tested it: on my Linux system, _bsddb
was not built, yet make reported success even after installing
your patch.
msg121406 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-18 01:37
(Side note: Specifying optional/required extensions from the command line may be an interesting new feature in distutils2.)
msg241744 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2015-04-21 20:50
I'm assuming that this will not be implemented until 3.6.
msg241793 - (view) Author: Jean-Paul Calderone (Jean-Paul Calderone) Date: 2015-04-22 09:49
It's only been six years, no need to rush.
History
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 50980
2019-09-03 08:53:24djcsetnosy: - djc
2019-03-15 22:08:01BreamoreBoysetnosy: - BreamoreBoy
2015-04-22 09:49:17Jean-Paul Calderonesetnosy: - exarkun, Jean-Paul Calderone
2015-04-22 09:49:02Jean-Paul Calderonesetnosy: + Jean-Paul Calderone
messages: + msg241793
2015-04-21 20:50:59BreamoreBoysetnosy: + BreamoreBoy

messages: + msg241744
versions: + Python 3.6, - Python 3.3
2010-12-14 03:26:28r.david.murraysettype: enhancement
versions: + Python 3.3, - Python 3.2
2010-11-18 01:37:06eric.araujosetnosy: + eric.araujo

messages: + msg121406
versions: - Python 2.6, Python 3.1, Python 2.7
2010-10-28 13:54:35djcsetnosy: + djc
2009-08-21 05:35:08loewissetmessages: + msg91801
2009-08-20 22:30:45Arfreversetmessages: + msg91792
2009-08-20 22:22:45loewissetmessages: + msg91791
2009-08-20 22:20:09loewissetmessages: + msg91790
2009-08-20 21:55:34Arfreversetmessages: + msg91787
2009-08-20 21:35:04gpolosetmessages: + msg91785
2009-08-20 21:06:38Arfreversetmessages: + msg91783
2009-08-19 22:35:41loewissetmessages: + msg91753
2009-08-19 22:25:11Arfreversetmessages: + msg91750
2009-08-19 21:02:34loewissetmessages: + msg91746
2009-08-19 20:34:42gpolosetnosy: + gpolo
messages: + msg91745
2009-08-19 20:27:46exarkunsetmessages: + msg91744
2009-08-19 20:26:29loewissetmessages: + msg91743
2009-08-19 20:09:22exarkunsetnosy: + exarkun
messages: + msg91740
2009-08-19 20:05:15loewissetmessages: + msg91739
2009-08-19 12:03:22Arfreversetmessages: + msg91726
title: Non-zero exit status of setup.py when building of extensions has failed -> Add option of non-zero exit status of setup.py when building of extensions has failed
2009-08-19 06:25:25loewissetversions: - Python 2.5, Python 2.4, Python 3.0
2009-08-19 06:25:09loewissetnosy: + loewis
messages: + msg91725
2009-08-18 22:25:20Arfrevercreate