Conditional required variables proposal about python-decouple HOT 8 CLOSED

All variables are required by decouple. If you have a condition, you could use plain python instead of changing decouple's api.

Can't you achieve what you want by:

DEBUG = config('DEBUG', cast=bool)
if not DEBUG:
    THIS_IS_REQUIRED = config('THIS_IS_REQUIRED', default='local-value')
THIS_IS_NOT_REQUIRED = config('THIS_IS_NOT_REQUIRED', default='local-value')

If you must have it declared and can't use the if, you should consider using the default parameter to None. This will avoid the UndefinedValueError.

from python-decouple.

Sorry, this is my fault, let me try explaining it again. A more precise sentence that describes my problem would be:
I'd like to be able to tell that some env variables must be set in a production environment.
(be it actually a environment variable, in an .env file or in an .ini file)

Therefore, a more precise implementation of the behavior I'm trying to achieve using the current API would be:

DEBUG = config('DEBUG', cast=bool)
if not DEBUG:
    THIS_IS_ANY_PYTHON_VAR = config('THIS_IS_REQUIRED_ONLY_IN_PRODUCTION')
else:
    THIS_IS_ANY_PYTHON_VAR = config(
          'THIS_IS_REQUIRED_ONLY_IN_PRODUCTION', default='local-value')
THIS_OTHER_PYTHON_VAR = config('THIS_IS_NEVER_REQUIRED', default='local-value')

Note that if DEBUG is False and the environment variable THIS_IS_REQUIRED_ONLY_IN_PRODUCTION is not set, it will raise an exception. If DEBUG is True, it will never raise an exception.

from python-decouple.

Hi @filipeximenes,

An alternative is to use decouple's undefined object, as in this example:

from decouple import config, undefined
DEBUG = config('DEBUG', cast=bool, default=False)
DB_NAME = config('DB_NAME', default='default-db-name' if DEBUG else undefined)

Best regards,

from python-decouple.

Cool, this fulfills my needs! Will close the issue.
Thanks!

from python-decouple.

Pretty cool, Fernando!!!

However, thinking about the project design, somehow I think Xima is
breaking the premisse that the settings should be production oriented and
developers should improve their environments to make their development
instances behave as they need.

Personally, I see the need of hardcoding test values as an anti-pattern.

from python-decouple.

@henriquebastos I put the word test under my example, not @filipeximenes. I've updated to default-db-name.

I agree with you that settings should be production oriented, but some times I use decouple as "a reasonable default value that I can use into development and can be changed on production without changing the code".

As Tim Peters said:

Special cases aren't special enough to break the rules.
Although practicality beats purity.

from python-decouple.

I have a situation where I have access keys to external services that are required for some actions in the system that not all developers will need to deal with. I don't want developers that are not working in this part of the system to bother with this keys, but at the same time I want to make sure my production environment has the correct configuration and screams if there's something missing.

I think the same applies when we set databases like this:

DATABASES = {
    'default': config(
        'DATABASE_URL',
        default='sqlite:///' + BASE_DIR.child('db.sqlite3'),
        cast=db_url
    )
}

There is a risk to end up with a sqlite database in production if someone forgets to set the DATABASE_URL environment variable.

from python-decouple.

I understand and share this need.

I just rather create a contrib shellscript to launch process with
dummy/dev config values instead of complicating the use of decouple and
risking a misbehavior in production. This can safely be added to the
repository under /contrib.

My rationale is: if it's a dev need, let's find a dev related solution
instead injecting ambiguity (in behavior) to the settings.py

Many options! Pick what suits you.

from python-decouple.