Using alembic.config.main redirects log output

Question

I have a script that performs database operations alongside an alembic API call to upgrade a newly created database to head. I am having an issue with a python logger instance where logs are written to a file using a module level logger.

Then the script invokes alembic.config.main(argv=alembic_args) to run a migration. However, every log statement after the alembic call, using the original logger instance, isn't written to the expected log file.

Here is an example script that reproduces the behavior.

#!/usr/bin/env python3

import logging
import os

import alembic.config

from .utilities import get_migration_dir

logging.basicConfig(filename='test.log',
                    level=logging.DEBUG)

CUR_DIR = os.path.dirname(__file__)
LOG = logging.getLogger('so_log')

LOG.info('Some stuff')
LOG.info('More stuff')

alembic_config = (
    '--raiseerr',
    'upgrade', 'head'
)

os.chdir(get_migration_dir())

alembic.config.main(argv=alembic_config)

os.chdir(CUR_DIR)

LOG.debug('logging after alembic call.')
LOG.debug('more logging after alembic call.')
print('Code still running after alembic')

Log file output

INFO:so_log:Some stuff
INFO:so_log:More stuff

stdout

INFO  [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO  [alembic.runtime.migration] Will assume transactional DDL.
print statement before alembic
Code still running after alembic

It seems as though the logger instance, LOG, is losing context or being directed elsewhere after calling the alembic API.

Also, I've tried running the alembic call in a separate thread which yielded the same result. What I expect to happen should be that log statements continue to write to the specified file after using alembic for migrations but that is not happening. And further, it's actually breaking the LOG instance for any code that's called afterward; Unless I'm just missing something here.

Answer 1

I just learned that fileConfig takes a keyword argument, disable_existing_loggers, which defaults to True. Simply adding disable_existing_loggers = False to the call to fileConfig in env.py e.g:

fileConfig(config.config_file_name, disable_existing_loggers=False)

appears to allow both logging configurations to work without interfering with each other (which may be preferred rather than having to choose one over the other, in some cases)