When trying to build a python package for distribution, compile errors are always ignored. The setup function will return successfully even if it was unable to compile some modules due to, for example, indentation errors.

The specific situation I'm trying to deal with, is a script that builds a large number of eggs, and trying to detect if something went wrong.

I see that this has been raised as a bug for setuptools:

http://bugs.python.org/setuptools/issue61

But it's not considered an issue because it's how distutils works.

distutils.util.byte_compile calls py_compile.compile, but does not pass a doraise argument to it.

The only suggestion for how to get tools that use distutils.util.byte_compile (like setuptools.setup and distutils.core.setup) to exit on an error is to monkey patch py_compile.compile to change its default doraise argument to True. That suggestion came from here:

http://stackoverflow.com/questions/2230843/how-can-i-detect-errors-programatically-when-building-an-egg-with-setuptools

supressing compile errors when making a distribution seems like a bug to me, but just having the option to easily change this behaviour would be great.

This may have been done on purpose, to allow nearly-valid Python files to be packaged.  In other bug reports we got some use cases: files used as templates; custom dialects converted by import hooks; 2.x and 3.x code in the same sdist.  In that light, I think distutils should not raise exceptions (to allow these use cases) but should log warnings (to help people catch legitimate errors).

Another use case from #10530: deliberately broken modules for testing.

It would also break some 2/3 compatible projects who have a python3 and a python2 file sitting next to each other and dynamically selected and imported based on Python version.

We all agree Python files with invalid syntax should be allowed, but some error message should be logged.  From the py_compile docs, this is already what the compile function does if the doraise argument is false (default), so what’s needed here is a unit test that makes sure we get a warning and the bad file is included in the sdist.

(I think we should not be concerned by the direct print to stderr instead of using proper logging: distutils uses its own logging system which lets one control the verbosity but does not have flexible filters, handlers and configuration, so in effect it’s like print to stderr.)

As a distribution maintainer of several Python modules, I've run into this bug twice in the past week.  In each case, the python file in question had a SyntaxError and failed to compile, but the error just scrolled past in a large log and was missed because no failure occurred until we attempted to package the result, and the .pyc files were missing.

While we managed to track the problem down fairly easily in both cases, if we only had folks working on the problem that didn't have lots of experience in tracking down build issues, this could have wasted a lot of otherwise valuable engineering time.

I understand the desire to be able to package files that fail to compile, but having that be the default seems to me like it fails basic expectations, even given how long this bug has been around.  I can't imagine that the number of deliberately-broken python files is particularly large compared to the number of python files that might get broken accidentally (or files that are "broken" for one version of python but not another) and so being required to maintain an exception list doesn't seem unreasonable.  (Neither does some amount of transition period -- one or two minor releases of Python? -- between the introduction of the mechanism and the change of the default.)

Would people be interested in a patch to that effect?

Again, I think this behaviour was a deliberate decision, not a patch.  Developers should use tests to detect syntax errors in their code, not rely on distutils byte compilation.

a deliberate decision, not a bug*

Absolutely true that developers should have tests that would detect such bugs.  However, the sooner you detect a bug, the more time you save.  And by the time it reaches someone like me, who is just packaging up the module for distribution with an OS, it's just going to waste my time, too, with less benefit (because I'm still not going to have much of an incentive to write tests).

Imagine if your C compiler only warned about code that wouldn't compile, and failed to produce the corresponding .o file without erroring out, and the linker failed to error out when that .o file was missing, and that you only noticed the problem when you ran your tests (or, if you're just shipping someone else's code, when your customer calls you to complain).  Wouldn't you think that was stunningly broken?

Again, I get that there are use cases for having broken code pass through unscathed, but it seems very odd to me (as someone with a long unix background) that this would have been a conscious default.  Now that it is the default, I understand the need for caution, but caution needn't (and shouldn't) prevent bugs from getting fixed.

Also agree setup allowing broken code an be annoying, but it is necessary to maintain the existing behavior.  Maybe we need an additional argument for setup that will in turn pass doraise to py_compile.compile, but retain the default behavior in all other cases?  As a work-around to your problem, try "pylint -E" before you build your package, we require it as a part of our build process.

It seems like this issue is not a bug, I close it.