Running GeoDjango in a Docker container - have added additional libraries via pip in the Dockerfile, and am now experiencing unwanted console output whenever I invoke any of the migrations commands, e.g. manage.py showmigrations/makemigrations/migrate.
The output is as follows:
user@host:/src$ ./manage.py showmigrations
CONFIGDIR=/home/django/.config/matplotlib
(private) matplotlib data path: /usr/local/lib/python3.7/site-packages/matplotlib/mpl-data
matplotlib data path: /usr/local/lib/python3.7/site-packages/matplotlib/mpl-data
loaded rc file /usr/local/lib/python3.7/site-packages/matplotlib/mpl-data/matplotlibrc
matplotlib version 3.2.1
interactive is False
platform is linux
loaded modules: ['sys', 'builtins', '_frozen_importlib', '_imp', '_thread', '_warnings', '_weakref', 'zipimport', '_frozen_importlib_external', '_io', 'marshal', 'posix', 'encodings', 'codecs', '_codecs', ...
Comprehensive modules listing snipped, it continues:
Using fontManager instance from /home/django/.cache/matplotlib/fontlist-v310.json
Loaded backend qt5agg version unknown.
Loaded backend tkagg version unknown.
Loaded backend agg version unknown.
Loaded backend agg version unknown.
Found GEOS DLL: <CDLL '/usr/local/lib/python3.7/site-packages/shapely/.libs/libgeos_c-5031f9ac.so.1.13.1', handle 5608f64e4c40 at 0x7f22a5aaaf10>, using it.
Trying `CDLL(libc.so.6)`
Library path: 'libc.so.6'
DLL: <CDLL 'libc.so.6', handle 7f22c4809000 at 0x7f22aef3b650>
GDAL_DATA not found in environment, set to '/usr/local/lib/python3.7/site-packages/fiona/gdal_data'.
PROJ data files are available at built-in paths
Entering env context: <fiona.env.Env object at 0x7f22a0798450>
Starting outermost env
No GDAL environment exists
New GDAL environment <fiona._env.GDALEnv object at 0x7f22a0798490> created
Logging error handler pushed.
All drivers registered.
GDAL_DATA found in environment: '/usr/local/lib/python3.7/site-packages/fiona/gdal_data'.
PROJ data files are available at built-in paths
Started GDALEnv <fiona._env.GDALEnv object at 0x7f22a0798490>.
Updated existing <fiona._env.GDALEnv object at 0x7f22a0798490> with options {}
Entered env context: <fiona.env.Env object at 0x7f22a0798450>
Exiting env context: <fiona.env.Env object at 0x7f22a0798450>
Cleared existing <fiona._env.GDALEnv object at 0x7f22a0798490> options
Stopping GDALEnv <fiona._env.GDALEnv object at 0x7f22a0798490>.
Error handler popped.
Stopped GDALEnv <fiona._env.GDALEnv object at 0x7f22a0798490>.
Exiting outermost env
Exited env context: <fiona.env.Env object at 0x7f22a0798450>
Could not import boto3, continuing with reduced functionality.
PROJ data files are available at built-in paths
Finally, the normal migrations output is displayed:
admin
[X] 0001_initial
[X] 0002_logentry_remove_auto_add
[snipped ...]
user@host:/src$
It's on a production system with gunicorn, NOT running in DEBUG mode. On the development system, with the same libraries set up, but in DEBUG mode, the output is normal. Dev and production dockerfiles are almost identical, stemming from python:3.7.4-buster.
On a first glance, it looks like a "chatty" library that is printing all that when it is loaded? Not sure if there is something broken or if this is normal? There are no signs of problems in the gunicorn error log. This also seems to only affect the migrations commands, no other manage.py commands.
Any hints appreciated!
Looking at the source for Fiona we find
log.debug("Entering env context: %r", self)
Since that's a debug level message, it wouldn't be visible by default.
This is a clue that logging has been configured to log debug-level messages.
This could happen via your Django config (which uses logging.dictConfig() under the hood), or by e.g. some module having run logging.basicConfig(level=logging.DEBUG).
Also, given how the .pth files that some packages use to hook themselves up to your import path work (they're just Python), this could inadvertently happen even if the package itself isn't imported.
I'd suggest removing some of those packages one by one until you find which one causes extra chattiness.