allow swagger and redoc settings to be overridden

[terencehonles]

When using site middleware there is no way to configure swagger instances to have different login URLs or authentication mechanisms. This change updates any global references to app settings to prefer a local setting if it exists, and for backward compatibility it refers to the global setting by default.

The following calls will need to be adjusted to account for the new swagger_settings parameter that is passed:

• drf_yasg.utils.get_produces(...)
• ViewInspector class (and user defined subclasses)
• Generator class (and user defined subclasses)

[axnsan12]

The motivation seems reasonable, but seems to require a lot of big changes.

Could you point to some other examples of how libraries deal with this? For instance, how does DRF itself acoomodate multiple sites?

If I'm getting it right, the gist of it is that all global settings should have a class or object-level alternative of obtaining the same effect?

[terencehonles]

@axnsan12 I'll have to see how DRF handles this itself. We've not had to tweak anything on DRF since most of the global settings have worked ok for us.

As far as the gist of it, that's correct. I'm just holding a reference to the user supplied settings object wherever it was needed. I aliased the global one to have a "_" prefix so linting would alert another developer that there was no non prefixed version of the settings in the local context and they should figure out if they should use the global context or if context was supplied locally. In the long term it would probably be best to remove the entry points for using the global settings so there's no confusion for future developers, but in order to maintain backward compatibility I kept the global settings as a fallback.

If you want comments or me to put the global fallbacks into a helper function w/ a deprecation warning I can change the code to do that.

[terencehonles]

Going through http://www.django-rest-framework.org/api-guide/settings/ most of the settings we would change on DRF would be possible through creating a base class per host and using that to supply overides to the permission classes or authentication classes. In our site we've not tried sharing serializers between sites so this hasn't been something we'd needed to worry about. DRF stays relatively extensible because it has an easy place to put the hooks to override things.

[axnsan12]

Hello!

I've been looking into it, and the approach of this PR doesn't seem optional to me.

However the general idea is solid and reasonable, so I'll be working to decouple/phase out global settings and, as you say, increase the extensibility of the various components that are currently using global settings. But the approach I'm imagining would be more localized rather than hauling the whole settings objects around everywhere.

[terencehonles]

I'm guessing you mean optimal rather than optional.

Anyways, I'll be maintaining this PR (as we are using the changes) until the rearchitecturing is made. I wrote the PR this way to integrate as easy as possible into the existing codebase without imposing changes to the architecture. I look forward to seeing the changes you envision.