django-pkgconf

Rick and Morty ©. Dude presents a battery, me too.

Not so long ago, I published a small application for the formation of "control panels" django-projects. In the process of development, I ran into a banal situation of storing default settings of the module. A quick github search made it clear that each developer uses his own implementation. There are also ready-made solutions, however, they seemed to me redundant in such a simple matter, so I acted wisely and washed down my bicycle.

It may seem that this battery will be useful only for OSP-shnik, but the thing is that this same idea can be used in everyday life.

"Banal situation"

Suppose you have written your application that does something there. At the same time, there is an opportunity in the project settings.py to set some values ​​that will be overwritten by those that come from the box. Overall, the whole task comes down to two things: store default values ​​and let the developer consumer rewrite them in their settings file.

Like this:

 #    app/my_settings.py FOO = True #    settings.py FOO = False #  ,  from django.conf import settings settings.FOO False 

We use in our project

Now it is customary to develop a project modularly breaking it into “applications”. Almost everything is rendered into individual app files: models, views, urls ... except settings. For example, you write the adapter to the mailing service and the following code in some newsletters/adapter.py :

 adapter = Adapter(username='user', password='pass') 

You will be right if you say that hardcodes login and password are stupid and they should be put into constants:

 USERNAME = 'user' PASSWORD = 'password' adapter = Adapter(username=USERNAME, password=PASSWORD) 

It seems to be close, but still not that. Another approach:

 # settings.py NEWSLETTERS_USERNAME = 'user' NEWSLETTERS_PASSWORD = 'password' # newsletters/adapter.py from django.conf import settings adapter = Adapter(username=settings.NEWSLETTERS_USERNAME, password=settings.NEWSLETTERS_PASSWORD) 

It looks like the truth. However, there are several "but":

• this NEWSLETTERS_ not very convenient. First, just more duplicate letters in the code; secondly, the values ​​may be more universal and used more often, which makes this reason all the more sad
• These settings do not apply to the project , but are needed for a separate application and, probably, are not used outside of it - so why keep them in the main file?
• If an app is developed by one person in a command, its commit is limited to the application directory.

django-pkgconf

Let's try this:

 # newsletters/conf.py from pkgconf import Conf class NewsLetters(Conf): USERNAME = 'username' PASSWORD = 'password' # newsletters/adapter.py from . import conf adapter = Adapter(username=conf.USERNAME, password=conf.PASSWORD) 

Conditions are fulfilled: there is no prefix, there is no cluttering up of the project settings file.
Override the values ​​in Dev settings *:

 # local_settings.py NEWSLETTERS_USERNAME = 'test_user' 

Is done. This will overwrite the USERNAME value for the configuration of the newsletters application, and the PASSWORD value will remain the same because we have not changed it. As a result, we get neat and slim settings.py , where DATABASES , TEMPLATES , etc. are all there, just what is related to the project .

Compatibility

Tests were conducted on python 2.7.9, 3.4.3, 3.5.0 and django 1.8, 1.9.

 Name Stmts Miss Cover ----------------------------------------- pkgconf/__init__.py 22 0 100% 

Project on githaba .

* Please do not do this, use django-configurations .