And a lot of the providers rely on static settings.  So writing a plugin system that patches the namespace of the settings.py module is somewhat inevitable, since there’s no way to do that currently in the codebase.  While the easiest way can appear to be for every operator of an openedx instance to just supply their own, customized settings.py file, speaking as a person who does runs deployment of OpenEdX, I can tell you that begin able to configure the system without forking settings.py is quite valuable.



On Mar 4, 2014, at 1:16 PM, johncox-google <notifications@github.com> wrote:

> In lms/envs/dev.py:
> 
> > @@ -285,6 +285,18 @@
> >  ### This enables the Metrics tab for the Instructor dashboard ###########
> >  FEATURES['CLASS_DASHBOARD'] = True
> >  
> > +##### Third-party auth #####
> > +if FEATURES.get('ENABLE_THIRD_PARTY_AUTH'):
> > +    # First, load in the third_party_auth django app.
> > +    INSTALLED_APPS += (
> > +        'third_party_auth',
> > +    )
> > +    from third_party_auth import settings as third_party_auth_settings
> > +
> > +    # Then patch in auth-specific settings onto this module. See common/djangoapps/third_party_auth/settings.py for how
> > +    # to specify options.
> > +    third_party_auth_settings.patch({}, sys.modules[__name__])
> The main source of complexity here is that the goal of this project is not to enable a small set of well-known providers (if only!). We need to do that and provide extensibility for providers tomorrow we don't know about today. That's what I mean by 'not enumerable a priori' -- we can't write down the providers we need to support, and we can't write down the settings they'll have.
> 
> If we do what you propose we'll still need a registry of enabled providers (different deployments will have different sets of enabled providers configured differently, and code that isn't fully written yet will need to probe and react to that set in order to do things like build the right login form UI, configure the urlspace, etc.). We'll also still need people to implement providers, patch secrets onto settings somehow, and manage the different settings configuration paths for dev/test/prod. That's all doable, but I think the end result would basically end up as complicated as this implementation. So I think the ROI of building it is pretty low, given that this implementation already exists.
> 
> —
> Reply to this email directly or view it on GitHub.
>