I get the following failure under a fresh checkout:

======================================================================
FAIL: test_package_data (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------

Traceback (most recent call last):
  File "/home/antoine/t/cpython/Lib/distutils/tests/test_build_py.py", line 61, in test_package_data
    self.assertTrue("__init__.pyc" in files)
AssertionError: False is not true

This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.

Duplicate of bpo-12117.

I have changed packaging in dad02a080bbc to work even under -O or -B.

packaging gives control over the creation of pyc and/or pyo files to the user with its own explicit options (--compile/--no-compile and --optimize 0/1/2), and the behavior should not change if the calling Python happens to run with -B or -O for whatever reason.

Other libraries make different choices: For example, compileall gives no option to generate pyo instead of pyc, you have to call it with python -O. I argue that distutils and packaging are different. Calling “python -B setup.py build” means that you don’t want pyc files to be created for the modules that are imported for this invocation, but it should not mean that distutils needs to behave as if --no-compile was given.

Fixing this is a small change, and in my opinion a bug fix. Of course, I would not remove the DistutilsByteCompileError to preserve compatibility, but I would remove the warnings/exceptions when running under -B. Can I do it?

A 1999 comment in build_py from Greg Ward agrees with me:

# XXX hey! we can't control whether we optimize or not; that's up
# to the invocation of the current Python interpreter (at least
# according to the py_compile docs).  That sucks.

If Tarek doesn’t object, I will make the change I proposed in my earlier message in distutils.

Please don't backport this change to distutils without backporting --no-compile options to "build" command in distutils (issue bpo-13400). Otherwise users would lose possibility of disabling byte-compilation during running this command.

distutils tests could use locally modified environment with PYTHONDONTWRITEBYTECODE variable removed.

Please don't backport this change to distutils without backporting --no-compile options to
"build" command in distutils (issue bpo-13400).
The feature freeze on distutils rules this out.

Otherwise users would lose possibility of disabling byte-compilation during running this command.
python setup.py build build_py --no-compile --optimize=0

I thought about this and am not sure about my position.

I am 100% convinced that what packaging does is the right thing. Modules like py_compile, compileall (in 3.2+) and packaging are able to compile with or without optimization depending on options that are given to them, independently from the optimization level of the calling Python.

distutils however depends on the calling Python’s -B and -O options, and I just don’t think there is much value in fixing this bug and causing obscure bugs for people who’ve been using -B to control distutils for the past months.

Antoine, you’re a pragmatist and a fixer of bugs. Arfrever, you’re using this misfeature. I’d like to know your opinion.

Can this be closed?

In the absence of support for doing the right thing (which would break compatibility), I won’t change distutils here.

Can we have a fix for this? ... one that would not require me to drop using PYTHONDONTWRITEBYTECODE.

I do have PYTHONDONTWRITEBYTECODE=1 on my user profile and installing packages became a nightmare.

See bpo-12117.