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

(from http://hg.python.org/cpython/file/cb297930d2cf/Lib/distutils/core.py#l12)

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).


[1] http://docs.python.org/dev/distutils/setupscript.html#debugging-the-setup-script

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.

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.

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.

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.

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?

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.

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.