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.

Title: allow distutils debug mode to be enabled more easily
Type: enhancement Stage: resolved
Components: Distutils Versions: Python 3.4
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: chris.jerdonek, dstufft, eric.araujo, jaraco, jeffknupp, tarek
Priority: normal Keywords: patch

Created on 2013-01-17 23:41 by chris.jerdonek, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
distutils.patch jeffknupp, 2013-01-18 18:15 review
Messages (8)
msg180161 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-17 23:41
This issue is to allow distutils's debug mode [1] to be enabled more easily (e.g. programmatically).

Currently, for example, distutils.core does the following:

    from distutils.debug import DEBUG


which means that it's not sufficient to set the DEBUG attribute on the distutils.debug module.  Instead, to enable debug mode programmatically you have to do something like the following prior to importing from distutils:

    import os
    os.environ['DISTUTILS_DEBUG'] = "1"  # "" for False or "1" for True.

This issue can be fixed simply by changing the affected import statements from importing the value to importing just the module (and subsequently accessing the value via the module).

msg180203 - (view) Author: Jeff Knupp (jeffknupp) * Date: 2013-01-18 18:15
Patch uploaded. 

Note that updating the test_distutils.core test revealed that the test was importing DEBUG from the wrong module (which only existed because distutils.core use the 'from ... import DEBUG' form). I've corrected the import and updated the test case.

Also updated the documentation to reflect the change.
msg180970 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-30 08:54
I meant to comment on the patch earlier.

The fix here isn't as simple as I had originally suggested.  The patch has to be constructed more carefully to be more fully backwards compatible.  For example, it shouldn't break code that imports DEBUG from modules, or that sets DEBUG on other modules.  The test case you found is an example of the former.
msg213350 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2014-03-13 04:16
I see the value in this small change, but this could only be changed in 3.5, making it mostly irrelevant for potential clients (i.e. packaging tools that extend distutils), as they keep compatibility with 2.7.  In the absence of requests by developers of these packaging tools, I am rejecting this request.
msg213387 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-03-13 12:01
I'm not sure I understand the justification. If the patch serves a logical purpose, and distutils isn't deprecated in the current development line, then I would suggest we apply the patch. If we don't fix the behavior today, then the library will be in the same boat 5 years hence. The argument that many still rely on 2.7 could apply to any patch applied to 3.x. Furthermore, having better debug capability in even one version could provide packagers with a target in which to troubleshoot.

I'd prefer the patch be accepted or rejected on merits.
msg213447 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2014-03-13 19:32
Thanks for weighing in.  (Adding Donald as pip representative.)

> I'd prefer the patch be accepted or rejected on merits.

The current patch is incomplete because not fully backward-compatible: even if we imported “distutils.debug” everywhere, we’d still need to support third-party code setting for example “distutils.core.DEBUG”.  To fix that, something like a custom module type subclass would be needed, which seems heavy-handed to me.  I weighed that cost against the benefits (slightly easier to change DEBUG status), saw that no developer of setuptools or pip had requested the change (but maybe because of distutils’ complicated maintenance status), and concluded that it was much trouble for little benefit.  Should I reconsider?
msg213448 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-03-13 19:37
That's entirely reasonable. I thought maybe that was the case.

My instinct is that 100% backward compatibility may not be necessary, especially if setuptools and pip are in the loop and can assure compatibility at some level. I'll dig deeper into the issue from a setuptools perspective and report back.
msg213512 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-03-14 02:58
Searching through the setuptools code base, there's no code reference to DEBUG and only one comment referencing DISTUTILS_DEBUG (which I'm suspicious may be a legacy artifact). In any case, I'm mostly confident that applying the patch as presented would have little consequence specifically to setuptools.
Date User Action Args
2022-04-11 14:57:40adminsetgithub: 61193
2014-03-14 02:58:20jaracosetmessages: + msg213512
2014-03-13 19:37:02jaracosetmessages: + msg213448
2014-03-13 19:32:59eric.araujosetnosy: + dstufft
messages: + msg213447
2014-03-13 12:01:19jaracosetmessages: + msg213387
2014-03-13 04:16:09eric.araujosetstatus: open -> closed

nosy: + jaraco
messages: + msg213350

resolution: rejected
stage: resolved
2013-01-30 08:55:37chris.jerdoneksetkeywords: - easy
2013-01-30 08:55:00chris.jerdoneksetmessages: + msg180970
2013-01-18 18:15:06jeffknuppsetfiles: + distutils.patch

nosy: + jeffknupp
messages: + msg180203

keywords: + patch
2013-01-17 23:41:54chris.jerdonekcreate