Hi, I'd like to describe how we've solved the per-package settings issue at our company.
Here's a little source code example: https://gist.github.com/wkornewald/9109270 Every Python package defines a module with a Config instance and then sets default settings on it. Instead of defining settings as global variables in a module you import all packages' config instances and set custom settings. Settings which require imports can be configured by using set_lazy() and passing lambdas/functions which do those imports on-demand. The lazy function's return value is cached. There's also a sandbox mechanism where you can do: with config: config.set(debug=True) # all code will now think we're in debug mode # and here we're back to the previous setting Sandboxing can be useful for unit tests. Anyway, please take a look at the code example in the link above. If you need more fine-grained control, you can of course also attach config instances to individual objects instead of packages. So, what do you think? Greetings, Waldemar Kornewald On Sunday, February 16, 2014 11:55:24 AM UTC+1, Aymeric Augustin wrote: > > Hi Schuyler, > > On 14 févr. 2014, at 15:18, Schuyler Duveen <[email protected]<javascript:>> > wrote: > > TLDR: Django modules should work as libraries (e.g. ORM, mail, etc). > "from django.conf import settings" bootstrap undermines this. > > > My use-case is Django's awesome (yes, I know opinions differ), > simple-to-use ORM. > > > For the ORM, settings aren't the primary concern. The biggest problem is > setting up relations between models. This needs to be done at some point > before you start using models. > > Before Django 1.7, the app cache took care of that at some ill-specified > and project-dependant point. During the app-loading refactor, we recognized > that such an important step couldn’t be left to chance and we introduced an > explicit bootstrap, `django.setup()`. > > Given the current implementation of `django.setup()`, it seems possible to > inject the settings there in another form that a Python module, if that’s > what you’re after. See > https://github.com/django/django/blob/master/django/__init__.py#L11-L21. > > It seems to me that you haven’t attacked the right problem for what you’re > describing as your primary use case. (That’s why I’ve been asking for a > mailing-list discussion since September.) > > Besides, you need a plan to replace `django.setup()`. > > For the first trial at this approach, we tried out utils.timezone: > > https://github.com/SlashRoot/django/blob/33c49245032115cf3fd6534d5a55313435419ffb/django/utils/timezone.py#L302 > > and it seemed to have worked, so we moved on to django.core.mail, and > other modules. > > > All the discourse around unsettings is based on the assumption that it’s > an incremental improvement that may provide some other benefits in the > future. > > However, the current results aren’t looking so good to me: > - The new APIs are weird: functions end up with additional keywords > arguments purely based on their implementation. This isn’t a good way to > design and API. (I assume that the goal of unsettings is to make these APIs > public.) > - It makes the code more complex: every contributor to Django will have to > learn a new way to inject settings into functions. In order to keep the > barrier to contributing to Django low, I’m not fond of such idiosyncrasies. > > Also, benefits still look quite hypothetical, if not theoretical. I’m > worried about beginning a path without a convincing explanation of why it > isn’t a dead-end. In the past, we’ve hit dead-ends on projects much better > planned that this one, eg. mitsuhiko’s “template compilation” GSoC. > > That makes me -1 on the concept for now. I don’t believe it beats the > status quo. To change my vote, I would need: > - a description of how you plan to deal with django.setup() — it seems > more complicated than dealing with settings; > - an explanation of what comes after we replace every “settings.FOO” with > “@unsettings(FOO=…)”; > - some thoughts of why we’re comfortable maintaining the resulting public > APIs in the long term. > > I have much more to say but I’ve tried to summarize my thoughts in this > email. I hope this helps. > > -- > Aymeric. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3f40c711-1b71-406a-acf5-79ca78161c49%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
