Hi Jarosław. Thanks for picking this up. 

There seems to be enough support for the general idea here, so worth 
pressing on. 

Let's think about any required deprecations on the PR. (It's easier there 
😅). 

Kind Regards,

Carlton

On Sunday, 24 April 2022 at 01:25:28 UTC+2 jaro...@wygoda.me wrote:

>  I'd like to introduce a file storage registry similar to 
> BaseConnectionHandler (django/utils/connection.py) and EngineHandler 
> (django/template/utils.py).
>
> Example settings.py snippet:
>
> STORAGES = {  # rename to FILE_STORAGES to make it more explictit?
>     'example': {
>         'BACKEND': 'django.core.files.storage.FileSystemStorage',
>         'OPTIONS': {
>             'location': '/example',
>             'base_url': '/example/',
>         },
>     },
> }
>
> Changes introduced by this pr are backward compatible. Users can still use 
> existing settings to configure static and media storages.
>
> Currently storages can be retrieved from the following objects:
>
> django/core/files/storage.py:
>
>     get_storage_class
>     DefaultStorage
>     default_storage 
>
> django/contrib/staticfiles/storage.py:
>
>     ConfiguredStorage
>     staticfiles_storage 
>
> What do you think about deprecating them?
>
> ​https://github.com/django/django/pull/15610
>
> FileField can be tackled in a separate pr.
>
> czwartek, 12 listopada 2015 o 11:25:57 UTC+1 ja...@tartarus.org 
> napisał(a):
>
>> On 8 Nov 2015, at 08:31, Marc Tamlyn <marc....@gmail.com> wrote: 
>>
>> > I'm definitely in favour of a format allowing multiple storage back 
>> ends referred to by name. For larger sites it is not unusual to manage 
>> files across multiple locations (eg several S3 buckets). The storage param 
>> to FileField would be allowed to be the key, and there would be a 
>> get_storage function like get_cache. 
>>
>> It would remove the assymetry between the default backends and per-field 
>> ones, which does feel a little odd. However I don’t think that’s a strong 
>> enough reason to go for more complicated. Ballooning dictionaries can feel 
>> overwhelming when looking at modern Django settings (for instance, the new 
>> templates configuration is more daunting than it used to be), and as 
>> pointed out, overriding is more fiddly. 
>>
>> For testing, you need to be explicit per-field no matter what, so it’s a 
>> change from an instance to a symbolic reference. The instance is probably a 
>> variable anyway by declaration of the test model, which I suspect is 
>> slightly easier to chase. 
>>
>> So I’d be slightly more in favour of the terse, tuple-based syntax. 
>>
>> J 
>>
>> -- 
>> James Aylett 
>> I make: devfort.com, spacelog.org 
>> Films: talktorex.co.uk 
>> Everything else: tartarus.org/james/ 
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/48fed52b-4ef4-49d2-8e8d-c3f8550a4731n%40googlegroups.com.

Reply via email to