Optionally load from os.environ

[jazzband]

Optionally load from os.environ

[jezdez]

Interesting, that's not a bad idea.

But this would only work for string based settings as accessing os.environ in Python doesn't really allow you to get any other type. Any idea how we could solve this?

[cguethle]

Well, what I was trying was a bit of coercion. The below snippet could be more comprehensive to attempt to guess at the type.

def env_var( value ):
        if str(os.environ[value]).lower() in ("true",):
            return True
        if str(os.environ[value]).lower() in ("false",):
            return False
        try:
            return int(os.environ[value])
        except Exception:
            pass

        try:
            return float(os.environ[value])
        except Exception:
            pass

        return os.environ[value]

In the case of dicts, you could delimit the object hierarchy.

A_SETTING = {
   'attr1': 5,
   'attr2': 10,
}

# in os.environ search for
A_SETTING--attr1
A_SETTING--attr2

Note sure when it comes to lists/tuples. You would have to have markup in them or peer env vars that denote types of other existing vars wrt Python types.

I actually thought I could have this working in a 'nice' way by implementing new or init on a BaseSettings class that everything builds from (aka configurations.Settings), however it doesn't appear that the settings classes are ever instantiated. And I can't modify static class attributes.

So here I am. Thought you might have some ideas to extend django-configurations to support such a notion natively in it's construction of the final settings object.

[cguethle]

Ooops. :)

[matthewwithanm]

IMHO if you're doing anything that involved, it's probably a better idea to delimit your settings in the settings module and then opt-in using a (plain old string) flag in os.environ. This could be accomplished by using a factory function for DJANGO_CONFIGURATION and, within it, mixing in the appropriate classes based on os.environ values. Coming up with a way of serializing non-string types just seems like a mess.

[jezdez]

Yeah, type guessing is a bad idea in that case, agreed. @cguethle can you elaborate what your use case is?

[jezdez]

Okay, closing the ticket for now as I haven't gotten feedback from @cguethle.

[cguethle]

That's fine. While a generic solution would be nice, I acknowledge the coercion problems. I have setup an alternative at this point.

Thanks!
Chris

iPhone Approved

On Sep 21, 2012, at 9:36 AM, Jannis Leidel [email protected] wrote:

Okay, closing the ticket for now as I haven't gotten feedback from @cguethle.

—
Reply to this email directly or view it on GitHub.

[jezdez]

Ah, gotcha, please do tell if it can be generalized.