homepage

This patch removes the custom log implementation from distutils.
It keeps the compatibility with the previous logger and its specific
CONSTANTE names. It add a sys.stdout stream handler so it produces the
same output.
It is based on logging now, and a logger for distutils is created
at the root of the package.
The patch does not introduce any deprecation warning though, on
distutils.log usage, but maybe that could be a good idea, so the people
that use distutils.log know they should use distutils.logger.
(I don't know how the deprecation process works in Python)

Hey Tarek!
I fear most of your revisions - including this - can make it into 2.6
and 3.0. Python 2.6 and 3.0 are now in maintenance mode. Your patch
doesn't fall under the category bug fix. You have to target 2.7 and 3.1.

Right now Distutils has also two warn styles:
- log.warn, that uses a pseudo-logging warning and push
 it to stdout depending on the treshold level 
- cmd.warn, that push the message directly to sys.stderr
So this has to be changed as well

I updated the patch.
Mine only changes log.py.

This patch changes the log.py in order to make use of the logging 
infrastructure.
There are few point tough worth of mention.
There're two separate stages when log.py is used:
 a) during the python interpreter build (let's call it bootstrap) 
 b) for every python setup.py cycle
During the bootstrap log.py doesn't seem have access to the logging 
module
(at least on the CentOS/Redhat/Suse build systems, but I assume is true 
for 
other platforms): in this case a fallback minimal logging is in place.
Once the python is in place (eg. installed) it can make use of the true 
logging: this happen when python setup.py <cmd> is used to create a 
python module.
A python intepreter built with the patch (from the latest python build) 
is hosted in:
http://download.opensuse.org/repositories/home:/cavallo71:/python-opt 

After more thinking, I think we can use a better strategy:
 
- adding a deprecate warning inside the log module 
 and keep the code as it is
- set in the __init__ module the regular logger 
- change every call in distutils from the old log system to the new
now for the access problem, can you explain me when+how it happens 
exactly ?
btw, in your patch: 
- you have a raise 
- "except:" should be "except ImportError:"
- in _log, Logger.level should be self.level, same for Logger.stream
- I don't see why LOG, DEBUG etc is defined only in the try:

Hi Tarek,
I agree that a change in that module is "risky" but a warning won't 
solve the main problem in the long run: anyway I'm not able to comment 
about the best strategy.
Now the access problem:
If an import logging is put into the log.py the (python) build fails 
complaining the missing time module (upon which logging depends): this 
happens during the bootstrap phase (the lib-dynload is not in the path 
unless changes to the build system).
This is shown in the suse build server where python gets compiled from 
scratch without a previously installed python (contrary to what usually 
happen on a normal system).
Attached there's the build error using a minimal log.py (susebuild.log).
About my patch:
 - removed the raise
 - now it catches only the ImportError
 - The Logger.stream (as the _log) is a "static" and it should really
 belong to all the classes not a particular instance: anyway
 this is used just during the bootstrap so it needs to provide
 a bare minimum support;)
 - INFO/DEBUG/etc are defined there because they're not
 used during the bootstrap (correctly, IMHO). If I had no fear
 to break the other modules I'd removed them from there as well:
 I haven't seen them used elsewhere.
PS. I'm waiting for the build to complete in order to confirm if 
everything works fine.

I still don't see the need to :
- rename Log to Logger
- remove DEBUG, INFO, WARN, ERROR, FATAL from the module
In the next version of python we will have to keep them 
in any case and add a deprecation warning
because third party tools might use them.
The only thing we have to add is the "logger" global variable that
will let us use the logging module (protected as you said by the 
ImportError
so basically:
try:
 import logging
 logger = _global_log = logging.getLogger('distutils')
except ImportError:
 logger = _global_log = Log()

Hi Tarek,
there is a new patch.
 - Logger is now back to Log
 - put back INFO/DEBUG etc.
 - Wrapped the code inside a try/except 
I removed the _global_logger/logger variables, because they're
superfluous: so the cound of the module exported symbols should be 
greatly reduced (debug, info, warn, warning, error and fatal).
The warning has been put to match the Logger warning method.
I'm waiting for the suse build server to rebuild the whole python 
interpreter: the system looks very busy so I can confirm later if 
there's been any issue during the build and with the smoke tests.

> I removed the _global_logger/logger variables, because they're
> superfluous
Yes but by adding "log" instead, and removing "log = _global_log.log"
you are breaking Distutils because its uses "log.log"
Besides, the rest seem OK.
I'll work on your patch, and add a few tests with it and let you know
when it's up, thanks !

I have reworked your patch a little bit so it works for Distutils. But I
still need to digg on the initialization problem to see if we can get
rid of the problem : the new logging will not get imported as well
during tests so it is not what we want yet

ok the problem occurs because site.py calls distutils.util.get_platform
in addbuilddir. I'll see what we can do in there.

Actually I think the problem (see the attached file susebuild.log) is 
in the module time.so: during the build the python interpreter has not 
access to it (it is dynamically loaded) and it fails.
If that works is because an already python is set in the system (and 
the ./configure prefix is set to /usr): on the suse build server the 
system is regenerated from scratch every time making possible to catch 
this sort of side effects.
This way to build it is called continuous integration and it works 
forcing a hands-off approach to the build-install-test cycle (I cannot 
stress enough about the impressive work done by the SuSE people).
I'll fire tonight a new build on the suse build server with the latest 
patch and a small smoke test (is should catch the most obvious errors).
But are you convinced about the need for the "import pdb; pdb.set_trace
()"? 
If everything goes fine the latest build should be in:
http://download.opensuse.org/repositories/home:/cavallo71:/python-opt
Moreover there are few external modules compiled using this "new" 
interpreter (imaging and setuptools at the moment): this should give a 
reasonable confidence the distutils is not broken after changes.

Hi,
the latest patch (custom-log.diff minus the import logging
at the begin) breaks the imaging python module build:
the log is in the file susebuild.failed.imaging.log.

Hi Tarek,
there is a colliding warn symbol: one defiend whiting import warnings 
as warn and another defined as warn = logger.warn (~ line 56).
It breaks all the modules build (see attached file 
susebuild.failed.imaging-2.log).
As soon I confirm the patch I'll publish the modified version (it is 
now building).

Antonio, I am starting to think that having distutils dependencies in
site.py smells bad.
I have sent a mail in python-dev about it, that is now discussed in
python-ideas to discuss the creation of a separated sysconfig module.
So this patch will be held until we take a decision for sysconfig.
Thanks for your work so far !

Hi Tarek,
This is the latest patch to log.py that compiles with the latest python 
svn 72494. It shows no problem with the few modules I've used so far: 
now I can't decide if this should go mainline or not but I'll leave 
here as reference anyway.
Cheers,
Antonio

Status update:
- site does not depend on distutils anymore in 2.7 and 3.2, now that distutils.sysconfig has been move to sysconfig.
- distutils is frozen, so it won’t get a refactor.
- Tarek is nearly done removing log in distutils2. Command.warn can also just use logging.warn to make things consistent.

distutils2.log has been removed in f6ef30a22a24.
I’m leaving this open to remind us we want to remove the warn and announce methods. Logging all the way!

> I’m leaving this open to remind us we want to remove the warn and
> announce methods. Logging all the way!
Now done.