Setting helpers

[jazzband]

Setting helpers

[jezdez]

Interesting idea, indeed.

I'd want to see this implemented as a separate settings class, to reduce the chance of slowing down the default implementation. E.g. I could see each of the settings attributes (that are strings) be automatically rendered with format given the current __dict__ of the class in question. That would mean that you couldn't refer to a setting in the string if it wasn't already defined above, but that's something that can be documented.

[matthewwithanm]

I've implemented something similar using a descriptor too; the problem I had with it though was that it tends to be confusing when dictionaries are involved:

class Base(Settings):
    A = 'world'
    B = TemplateProperty('hello {A}')  # Yay!
    C = {
        'd': TemplateProperty('hello {A}')  # Boo!
    }

When you know the implementation, it's obvious why this wouldn't work, but it doesn't quite gel with the user's desired effect which is, essentially, a lazily evaluated string.

[jezdez]

Yeah, the descriptor implementation seems indeed like a slightly unintuitive API, or at least there isn't a well established convention in Django that would be close to that, making it harder for users to just jump in. Most settings are iterables or otherwise easy to inspect types, even though Django doesn't enforce that. So question is if this app should do that. E.g. I could see the app to iterate over a distinct set of types (iterables, OrderedDict/SortedDict, sets) to "render" them their values before setting the module level variables.

But on the other hand I'm also hesitant to add a full validation system. Do you think that rendering the variables could be instead just an option of a separate Setting class, e.g. a template=True option, that would explicitly enable the template rendering? An own Setting class would also be the place where type specific preparation could happen, e.g. a ListSetting class that would provide an easy API for modifying the order of its value, for example for the MIDDLEWARE_CLASSES setting.

Others could there be, too: DictSetting with an sorted parameter, as well as the template of course; the AppSetting that would act like a DictSetting but would have a required prefix parameter, effectively grouping the settings for 3rd party apps.

[keimlink]

I thought a helper to get the absolute path of the project directory would also be helpful. I need this in every project for template directories, static files and other stuff.

This could be implemented in a separate class with a generated attribute or using a helper method which could be used to assign the value to an attribute of choice.

[saulshanabrook]

@keimlink I have implemented this in my settings. I have it generate the path from the manage.py file.

import imp
import os


class RelPath(object):
    @property
    def SITE_ROOT(self):
        return os.path.dirname(imp.find_module('manage')[1])

    def rel_path(self, relative_path):
        '''
        given any path relative to the `SITE_ROOT`, returns the full path
        '''
        return os.path.normpath(os.path.join(self.SITE_ROOT,
                                             relative_path))

#Example usage
class Media(RelPath):
    MEDIA_URL = '/media/'

    @property
    def MEDIA_ROOT(self):
        return super(Media, self).rel_path('tmp/media/')

[jezdez]

So there was recently some discussion about this in Django core which led to the addition of the BASE_DIR setting to the project template but no the global settings that are used by configurations as the default values: https://github.com/django/django/blob/25f2acfed0fc110f88abbfffb5c5c62a76670db0/django/conf/project_template/project_name/settings.py#L11-L13

I've also thought more about this kind of feature and would rather not bless one of the patterns for now since there doesn't seem to be a clear set of helpers that would improve configurations. I'm closing this ticket for now but would encourage you to work on patches for specific helpers instead.