date:20190509

Re: injecting settings

2019-05-09 Thread J. Pic

In the example Config.ready() calls for a dict update() which will
probably work for a while, before changing the update() call in the example
with more elaborated code.
System checks shoud catch cases where configuration is invalid at all.

Not sure how much you can pull from entry points, if you want to keep
INSTALLED_APPS, but have a hook for your app to autoconfigure itself when
added maybe something like this:

[django.middleware]
DebugToolbarMiddleware = debug_toolbar.middleware.DebugToolbarMiddleware

Otherwise a freeform callbacks should be more flexible to provision common
stuff apps contribute to such as urls, middlewares, template engines ...

It's true that it doesn't look like you're going to be able to meta program
settings really profoundly, ie. different packages wanting different
defaults, but at least seems it can automate most of the work when
installing an app from the ecosystem into a new django project, that could
at least hook sane defaults, for example django-debug-toolbar's AppConfig
could provision middleware and urlconf and then you would only need to add
debug_toolbar to INSTALLED_APPS.

Does INSTALLED_APPS allow to plugin in a given AppConfig with arguments ?
Ie. in cakephp 3.7 that was just released they don't have a list such as
INSTALLED_APPS, but instead you add apps as such:

# that's all they need to setup the debug toolbar in cakephp
Plugin::load('DebugKit')

# but you could load a plugin without having urls injected as such:
Plugin::load('Cors', ['routes' => false]);

Which would be equivalent to something like:

INSTALLED_APPS.load('debug_toolbar')
INSTALLED_APPS.load('otherapp', urls=False)

It looks like app maintainers really ought to give django-gdaps a shot.
Perhaps Christian, another way would be to contribute gdap support to the
apps you like to use in the ecosystem. Then their maintainers could benefit
from it if they install gdaps and so it can propagate in the ecosystem, and
you can consolidate your patterns.

Best

--
∞

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAC6Op1_dMFwwxPwECqc8hk%3DT5HFkcMJjaE3VJ%3Dgo8W_%2B72a5Zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: injecting settings

2019-05-09 Thread J. Pic

ERRATA in the code above, a mistake I make really often, instead of:

DebugToolbarMiddleware = debug_toolbar.middleware.DebugToolbarMiddleware

Should be:

DebugToolbarMiddleware = debug_toolbar.middleware:DebugToolbarMiddleware

In one python module I rely on this (cli2), I ended just making so that
both forms work ^^

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op196pwJs0%2B_uuq4OtLg1E%2B%3D-dPjOUhp7Exk1p-1T5BS7Ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: injecting settings

2019-05-09 Thread Christian González


>
> It looks like app maintainers really ought to give django-gdaps a
> shot. Perhaps Christian, another way would be to contribute gdap
> support to the apps you like to use in the ecosystem. Then their
> maintainers could benefit from it if they install gdaps and so it can
> propagate in the ecosystem, and you can consolidate your patterns.
>
That's what I wanted when I created GDAPS. It should be an extension,
and not replace Djangos app loading mechanism. Not all applications are
designed to be pluggable, so a deterministic order in INSTALLED_APPS is
fine. How I designed it, was meant to *enable* Django apps to be
pluggable just by adding gdaps to INSTALLED_APPS.

But yes, this "sane defaults" what I need there would be handy in lots
of other Django apps, like you mentioned django-debug-toolbar.

And it's not about settings, but also e.g. urlpatterns - apps should be
able to inject them too. I found a way that works in GDAPS, using my
(adapted from pyutilib) plugin system.

The main settings/urls.py file could/should always be the master - this
is different in every application. Think of ordering urls.

Christian

-- 
Dr. Christian González
https://nerdocs.at

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8b8bf367-3026-fecd-4bf1-3c13327f12a2%40nerdocs.at.
For more options, visit https://groups.google.com/d/optout.


pEpkey.asc
Description: application/pgp-keys

Re: injecting settings

2019-05-09 Thread J. Pic

Maybe you would want to install an app without having their urls injected
then you're going to need to do things like

INSTALLED_APPS = [
 someapp.AppConfig(urls=False)
]

Of course this is going to make complicate the settings system, but why not
hook a callback in AppConfig that is executed in-between the moment
settings are parsed and the moment they are loaded into Django ?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op18yUasg74LVeW9FVQCA%3Dx%2BEnP3KhuDtRh_t8L5UtGkDkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django Async DEP

2019-05-09 Thread Andrew Godwin

Hello everyone,

While the ASGI patch (https://github.com/django/django/pull/11209) is maybe
the first small step in a long road to async, it's the only real one we
could do without a DEP as it purely pulls on existing specs and bugs.

To that end, I have drafted a DEP (provisionally #0009), "Async-capable
Django". It is a summary - and I use that word very lightly - of the rest
of the work to be done to make a version of Django that one could call
"async capable".

You can view it here:
https://github.com/andrewgodwin/deps/blob/async/draft/0009-async.rst

It is approximately 7,000 words long - while it could probably do with some
editing, the subject matter means it has to be quite in-depth. Even then,
it does not propose an exact plan to follow; instead, it proposes the
overall strategy and the high-level ideas about what needs to be done.

If you are short on time, please read the Foreword and the High-Level
Summary, and then jump around using the table of contents to the sections
that interest you.

Feedback on this is very much appreciated; you can either reply here or, if
you have comments that would benefit from precise location on the diff, use
the pull request here: https://github.com/django/deps/pull/56

This is a very complex topic, and I appreciate feedback might take a while;
at least a couple of weeks to get everyone's thoughts. If you want a more
private channel to discuss concerns or design questions you're not happy to
talk about publicly, feel free to email me directly.

This proposal does not quite fit the DEP template - we never really planned
for something of this scale - but I have done my best to make it work; I
think we still benefit from discussing and voting on it in the DEP format,
but suggestions on how to make it work better are welcome, provided they
fit within how Django operates as a community now.

Finally, if there is positive feedback on this, we have the separate
question of funding it that I will discuss separately, if and when we get
that far. The DEP covers some of the topics, but it's notable that the
implementation speed of this varies considerably; if we could get, say, me
and someone else on it full-time (which is not a cheap or likely prospect),
we can probably be done inside of a single release. If we rely just on
volunteer time, it may take years. There is hopefully somewhere between
those two that works.

Thanks for taking the time to read through!

Andrew

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFwN1uqav3JXQA3m%2Bajf0Bd15QQX3JTZTfmH3Hc3ECWyRR3CVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

25 matches

Mail list logo