Re: Provide a way to pass kwargs when initializing the storage class

Hi folks, STORAGES PR is in a really good shape. Can you please test this patch on your projects? Checking pending patches is a great way to contribute  Best, Mariusz -- You received this message because you are subscribed to the Google Groups

Re: Provide a way to pass kwargs when initializing the storage class

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

Re: Provide a way to pass kwargs when initializing the storage class

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':

Re: Provide a way to pass kwargs when initializing the storage class

On 8 Nov 2015, at 08:31, Marc Tamlyn 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 >

Re: Provide a way to pass kwargs when initializing the storage class

On Sunday 08 November 2015 10:31:06 Marc Tamlyn wrote: > > (Side point: a temp dir based storage which could clean itself up between > rest runs would be amazing) > Yes, it would. https://code.djangoproject.com/ticket/23251

Re: Provide a way to pass kwargs when initializing the storage class

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

Re: Provide a way to pass kwargs when initializing the storage class

The drawback of complex dictionary settings is that to overwrite only one key in a settings file, you have to copy the entire dictionary, also possibly defeating global settings defaults when they change. So let's try to have many smaller dictionaries instead of few big ones. The initial

Re: Provide a way to pass kwargs when initializing the storage class

+1 to these ideas. This will make injecting dependancies much cleaner. I’ve pointed my BACKEND settings to factory functions in the past. def storage_factory(): return SomeStorage(some_de) DEFAULT_STORAGE_BACKEND = ‘path.to.storage_factory' > On Nov 7, 2015, at 7:10 AM, Shai

Re: Provide a way to pass kwargs when initializing the storage class

On Saturday 07 November 2015 14:55:20 Aymeric Augustin wrote: > > Essentially your proposal means reformatting the current file-related > settings to this structure: > > FILE_STORAGES = { > ‘media’: { > ‘BACKEND’: settings.DEFAULT_FILE_STORAGE, > ‘OPTIONS’: { >

Re: Provide a way to pass kwargs when initializing the storage class

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

Re: Provide a way to pass kwargs when initializing the storage class

On Sat, Nov 7, 2015 at 11:58 AM, Raphaël Barrois 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

Re: Provide a way to pass kwargs when initializing the storage class

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

Re: Provide a way to pass kwargs when initializing the storage class

I'm +1 on this solution; it solves the problem in an efficient way without becoming unreadable. I'd shy away from the variants unless/until there's a definite need. kwargs are more explicit, which I think is helpful in readability :) J On Saturday, November 7, 2015 at 12:16:05 PM UTC+1,

Re: Provide a way to pass kwargs when initializing the storage class

I think the proposed approach makes sense. I don't think we need to support any variant to pass the configuration values as args. All the existing storage backends have to make their argument optionals anyway now to support how they are currently initialized. Requiring a dict makes it also

Re: Provide a way to pass kwargs when initializing the storage class

I think the proposed approach makes sense. I don't think we need to support any variant to pass the configuration values as args. All the existing storage backends have to make their argument optionals anyway now to support how they are currently initialized. Requiring a dict makes it also

Re: Provide a way to pass kwargs when initializing the storage class

Ooooh. I think I like it. The syntax could be a bit confusing, but I think I like it. :) On Saturday, November 7, 2015 at 12:16:05 PM UTC+1, Aymeric Augustin wrote: > > Hello, > > Currently the DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings > contain a dotted Python path to the storage

Provide a way to pass kwargs when initializing the storage class

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