Hello,
Indeed, if we took a big step further and provided an API to configure multiple
file storage backends, that would make sense.
Currently we have two hardcoded ones: the default, which is used for media
files, and the static, which is used for static files.
Essentially your proposal means reformatting the current file-related settings
to this structure:
FILE_STORAGES = {
‘media’: {
‘BACKEND’: settings.DEFAULT_FILE_STORAGE,
‘OPTIONS’: {
‘location’: settings.MEDIA_ROOT,
‘base_url’: settings.MEDIA_URL,
# possible override of settings.FILE_CHARSET
},
},
‘static’: {
‘BACKEND’: settings.STATICFILES_STORAGE,
‘OPTIONS’: {
‘location’: settings.STATIC_ROOT,
‘base_url’: settings.STATIC_URL,
# replacement for STATICFILES_FINDERS and STATICFILES_DIRS that
would look a lot like template loaders
# possible override of settings.FILE_CHARSET
},
}
}
The FILE_UPLOAD_* settings wouldn’t change because they don’t affect file
storage.
It isn’t entirely clear to me what the best way to reconcile “default” and
“media” would be. Currently they’re effectively the same but settings are named
inconsistently for historical reasons. In addition this would require an API
for getting a file storage backend.
This is a much more invasive change as it would require everyone to update
their settings. However it would meet some use cases much better. Pluggable
apps that need to store files could document that they’ll use the backend with
a given name it if exists and fall back to the default backend otherwise.
That’s exactly what django.contrib.sessions currently does with cache.
How do people feel about this alternative proposal?
--
Aymeric.
> On 7 nov. 2015, at 12:58, Raphaël Barrois <raphael.barr...@gmail.com> wrote:
>
> Hello,
>
>
> The core of the proposed solution seems quite interesting; however, it also
> introduces a new configuration format for backends.
>
> Caches and databases use a dict with a "BACKEND" key and an "OPTIONS" dict
> for kwargs to pass to the backend.
> Likewise, entries in the TEMPLATES list are dicts with a "BACKEND" key and
> various options.
>
>
> Do you think that the new setting should match these options instead of the
> proposed two-tuples?
>
>
> --
> Raphaël
>
>
> On Sat, 7 Nov 2015 12:15:49 +0100
> Aymeric Augustin <aymeric.augus...@polytechnique.org> wrote:
>
>> 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?
>>
>
> --
> 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 django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> 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/20151107125832.440abc17%40corvis.
> For more options, visit https://groups.google.com/d/optout.
--
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 django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
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/AC9ACBF4-1F90-4CA9-8DCA-2D43522581BF%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.
