Hi Schuyler, On 14 févr. 2014, at 15:18, Schuyler Duveen <[email protected]> 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/5FB6B896-8210-48DB-9942-A190BDCFFFC0%40polytechnique.org. For more options, visit https://groups.google.com/groups/opt_out.
