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 <schuy...@gmail.com<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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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.
