Issue 12119: distutils and python -B (original) (raw)

Created on 2011-05-19 16:20 by pitrou, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (12)
msg136301 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-19 16:20
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
msg136321 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-05-19 17:31
This is due to PYTHONDONTWRITEBYTECODE being set. Not sure this is worth fixing.
msg136344 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-05-20 00:11
Duplicate of #12117.
msg146943 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-03 16:31
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?
msg147488 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-12 14:28
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.
msg148500 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-11-28 16:24
Please don't backport this change to distutils without backporting --no-compile options to "build" command in distutils (issue #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.
msg148502 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-11-28 16:26
> Please don't backport this change to distutils without backporting --no-compile options to > "build" command in distutils (issue #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
msg154202 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-02-25 08:02
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.
msg185420 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-03-28 10:18
Can this be closed?
msg185451 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-03-28 14:37
In the absence of support for doing the right thing (which would break compatibility), I won’t change distutils here.
msg185468 - (view) Author: Sorin Sbarnea (ssbarnea) * Date: 2013-03-28 20:02
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.
msg185469 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2013-03-28 20:14
See #12117.
History
Date User Action Args
2022-04-11 14:57:17 admin set github: 56328
2013-03-28 20:14:39 eric.araujo set messages: +
2013-03-28 20:02:05 ssbarnea set nosy: + ssbarneamessages: +
2013-03-28 14:37:45 eric.araujo set status: open -> closedmessages: + stage: commit review -> resolved
2013-03-28 10🔞38 georg.brandl set status: pending -> opennosy: + georg.brandlmessages: +
2012-02-25 08:02:03 eric.araujo set status: open -> pendingresolution: fixedmessages: +
2011-11-28 19:27:10 vstinner set nosy: - vstinner
2011-11-28 16:26:12 eric.araujo set messages: +
2011-11-28 16:24:47 Arfrever set nosy: + Arfrevermessages: +
2011-11-12 14:28:48 eric.araujo set messages: + title: test_distutils failure -> distutils and python -B
2011-11-03 16:31:34 eric.araujo set status: closed -> openmessages: + assignee: tarek -> eric.araujoresolution: duplicate -> (no value)stage: commit review
2011-05-20 00:11:39 vstinner set status: open -> closednosy: + vstinnermessages: + resolution: duplicate
2011-05-19 17:31:12 pitrou set messages: +
2011-05-19 16:20:59 pitrou set nosy: + alexis
2011-05-19 16:20:53 pitrou create