--setting_module Option #8
Conversation
Allow logan apps to accept a --settings_module option that takes a dotted string representing an import path (e.g. my_module.settings). This value eventually gets run through __import__ and makes it possible to look up the module object by __name__ in sys.modules while loading the config for the logan app.
|
Taking a second look at the diff, I might be overloading the mod_or_filename param to load_settings a little too much. The assumption that an import error means the value is a filename might hide the problem when the value is supposed to be a module name but is just wrong. |
|
Unless I'm misunderstanding this, the point of config is that you can actually pass a file path (instead of a module). Given that case I don't see much of a point in incorrectly renaming it. If there's actual broken behavior then we should definitely fix that On Dec 14, 2012, at 9:25 AM, John MacKenzie [email protected] wrote:
|
That is correct. The That second paragraph in the original request was purely philosophical; I was just commenting on how most Python CLI tools I've interacted with usually take the dotted form of a module and import it rather than the path to the file. I avoided breaking |
|
Have you given any more thought on this? I'm maintaining an internal fork of logan that I'd like to get rid of. The few people I've talked to about this have thought it was a good idea and further criticized the way in Sentry, for example, you have to pass a path to a config file rather than a module name. |
I have a little library here at work (configtools) that helps me mange Django settings in config files and making a module kind of act like django.conf.settings by pulling config from some other preconfigured module (considering open-sourcing it, but that's beside the point). It makes use of something like sys.modules[name] to get access to the current module object at import time. Unfortunately, the way Logan handles the --config option and loading the file breaks that. This new option takes a dotted module name that gets passed almost directly to import fixing my problem.
I'd almost recommend replacing --config with --settings_module as, with my experience in the python community, most always you refer to a module or function in it's dotted form (e.g. package.module or package.module:function) when passing them as arguments to command line tools (see DJANGO_SETTINGS_MODULE, how you launch an app with gunicorn, etc...). This keeps backwards compatibility with --config and prevents both from being passed at the same time.