Hello,

Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings contain a 
dotted Python path to the storage class. The class is instantiated without any 
arguments.


** Problem **

This leads to three annoyances.

1) Third-party libraries like django-storages(-redux) need to provide a setting 
for every value that could be required to configure the storage. This 
additional level of indirection is annoying.

If you’re skeptical, look at 
https://github.com/jschneier/django-storages/blob/f2880b16b57a36b241a54932255e1a852c0e0ac7/storages/backends/s3boto.py#L204
 
<https://github.com/jschneier/django-storages/blob/f2880b16b57a36b241a54932255e1a852c0e0ac7/storages/backends/s3boto.py#L204>.

2) Compounding this problem, third-party libraries that want to use a Django 
storage backend, but likely not the default one, have no convenient way for the 
user to configure the storage.

Having settings such as `MY_THIRD_PARTY_APP__AWS_ACCESS_KEY_ID` etc. for every 
possible storage-related setting sounds unreasonable.

(This is the problem I’m facing right now with one of my libraries.)

3) The standard pattern for working around these problems is boilerplate-ish:

my_config = {foo: bar}

class ConfiguredStorageClass(GenericStorageClass):
    def __init__(self, *args, **kwargs):
        kwargs.update(my_config)
        super().__init__(*args, **kwargs)

DEFAULT_FILE_STORAGE = 'path.to.ConfiguredStorageClass'


** Proposed solution **

To solve this problem, I would like the DEFAULT_FILE_STORAGE and 
STATICFILES_STORAGE settings to accept an additional format: a 2-uple of 
(dotted Python path to class, init_kwargs).

This would allow simplifying the example above to:

DEFAULT_FILE_STORAGE = ‘path.to.GenericStorageClass’, {foo: bar}


** Variants **

We could go a bit further support 2-uples with args, 2-uples with kwargs, and 
3-uples with args and kwargs. I didn’t propose it because I’m not sure this 
possibility adds much value. Arguments can be passed as kwargs even if the init 
method expects them positionally.

We could support setting DEFAULT_FILE_STORAGE and STATICFILES_STORAGE to an 
already initialized instance of a storage class. I’m against this idea because 
settings should remain primitive Python values whenever possible.

We could introduce DEFAULT_FILE_STORAGE_INIT_KWARGS and 
STATICFILES_STORAGE_INIT_KWARGS. Well. Perhaps not :-)


What do you think?

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2B23D931-47E3-436F-A8E1-C4E06DB4B6D8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
  • Provid... Aymeric Augustin
    • R... Collin Anderson
    • R... charettes
    • R... charettes
    • R... James Aylett
    • R... Raphaël Barrois
      • ... 'Tom Evans' via Django developers (Contributions to Django itself)
      • ... Aymeric Augustin
        • ... Shai Berger
          • ... Sean Brant
    • R... Claude Paroz

Reply via email to