startproject values for STATICFILES_DIRS and TEMPLATES

[René Fleschenberg]

Hi,

It is quite common to configure TEMPLATES and STATICFILES_DIRS such that you 
can override the templates and static files of installed apps from some 
central location.

Maybe startproject should actually generate settings to do this by default?

STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)

Or maybe:

STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'mysite', 'static'),
)

In my experience, this is a real pain point for beginners, and doing this 
shouldn't hurt anyone. What do you think?

Also, do you think that templates and static files should be treated 
differently in this regard? The docs currently suggest such a configuration 
for static files, but not for templates. I'd argue that it's more important 
for templates, but it cannot harm to do it for both.

-- 
René Fleschenberg

-- 
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/8237964.u2MXdYcyU2%40rex.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - November 7, 2015

[Tim Graham]

I didn’t do too much triaging and reviewing this week due to traveling and 
Django Under the Hood. I started releasing 1.8.6 on a train from Brussels 
to Amsterdam and uploaded it upon arrival. We had a nice day of sprints 
today and now I have a plethora of pull requests to review. :-)

Triaged

---

https://code.djangoproject.com/ticket/25679 - ModelForm.Meta.fields and 
exclude are not honoured for custom fields (invalid)

https://code.djangoproject.com/ticket/25696 - Add sphinx extension to 
django.contrib (wontfix)

https://code.djangoproject.com/ticket/25690 - Migration operations should 
be ordered to prevent all columns from being removed (duplicate)

Probably a few more that I didn’t track...

Reviewed/committed

--

https://github.com/django/django/pull/5534 - Fixed #25132 -- Documented how 
to retrieve a single value using values_list() and get().

https://github.com/django/django/pull/5533 - Fixed #24244 -- Documented 
contrib.admin.models.LogEntry

https://github.com/django/django/pull/5537 - Fixed #25660 -- Documented 
GEOSGeometry.dims
https://github.com/django/django/pull/5564 - Fixed #25692 -- Added natural 
keys support to the Site model
(some other trivial ones from the sprint)

-- 
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/e0dc2d22-d345-43c8-9908-e02f8c1d6b48%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Claude Paroz]

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 proposal was a bit better at this regard.

Claude

-- 
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/e180cd2b-9601-44cd-9ba4-21e3a7d10157%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Sean Brant]

+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 Berger  wrote:
> 
> 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’: {
>> ‘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
>>},
>> 
>>}
>> }
>> 
>> 
>> How do people feel about this alternative proposal?
>> 
> 
> This, in general, seems like the right thing to do. The only reservation I 
> have is that the 'OPTIONS' key seems superfluous -- why not put the options 
> in 
> the same dictionary as the backend?
> 
> On a related point -- I wouldn't put base_url in there. It is related to 
> files, 
> but not to their storage.
> 
> My 2KB,
>   Shai.

-- 
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/06F33052-6FEB-48E0-821F-95E34893B30A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Shai Berger]

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’: {
>  ‘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
> },
> 
> }
> }
> 
> 
> How do people feel about this alternative proposal?
> 

This, in general, seems like the right thing to do. The only reservation I 
have is that the 'OPTIONS' key seems superfluous -- why not put the options in 
the same dictionary as the backend?

On a related point -- I wouldn't put base_url in there. It is related to files, 
but not to their storage.

My 2KB,
Shai.

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

[Aymeric Augustin]

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  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  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
>> .
>> 
>> 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 

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

['Tom Evans' via Django developers (Contributions to Django itself)]

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 "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?

I like explicit:

STORAGE = {
'default': {
'ENGINE': 'path.to.foo.Storage',
'OPTIONS': { ..}
},
}

Cheers

Tom

-- 
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/CAFHbX1JGG%2BJJStg%2BRK9ZZzXRi0zyi4QUjSLqQqNqoh1KGU2XnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Raphaël Barrois]

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  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
> .
> 
> 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.

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

[James Aylett]

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, Aymeric Augustin 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
> .
>
> 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 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/6fc3d5fc-b41d-4e08-9271-2db6c894f83c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[charettes]

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 more explicit about what values actually 
mean and support both cases.

Simon

Le samedi 7 novembre 2015 12:16:05 UTC+1, Aymeric Augustin a écrit :
>
> 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
> .
>
> 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 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/572e112e-e038-4f96-9ae9-45b2be612f11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[charettes]

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 more explicit about what values actually 
mean and support both cases.

Simon

Le samedi 7 novembre 2015 12:16:05 UTC+1, Aymeric Augustin a écrit :
>
> 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
> .
>
> 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 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/c372c115-5245-4410-8c0b-4a2153d0316d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Collin Anderson]

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 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
> .
>
> 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 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/1925ceb5-9855-4eba-944b-3841ad11fb56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Provide a way to pass kwargs when initializing the storage class

[Aymeric Augustin]

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
 
.

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 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/2B23D931-47E3-436F-A8E1-C4E06DB4B6D8%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: An issue with Django 1.8.6 support for south migrations

[Andrew Godwin]

That's an excellent point, Shai - if there are migrations they might be
essential to the app functioning. I think in that case we should not have
them work on 1.7 and up, and encourage people to send PRs to the apps
moving the directory name if it would work with syncdb.

Andrew

On Sat, Nov 7, 2015 at 11:28 AM, Shai Berger  wrote:

> No, I think we can't do this generically.
>
> If an app ships (South) migrations, we cannot assume that syncdb is an
> adequate replacement; the migrations may include data-migrations which
> create
> records the app needs. We could in general do something like, try to verify
> that there are no data migrations (this is easier with South migrations
> than
> with Django migrations), or ask the user for confirmation, or add a
> "ignore-
> south-migrations" setting to list the relevant apps, or find some other
> way for
> the user to tell us that syncdb is ok for this app, but IMO that takes us a
> step beyond Andrew's "fix is easy".
>
> Shai.
>
>
> On Saturday 07 November 2015 12:13:02 Andrew Godwin wrote:
> > I think if the fix is easy, we should continue to support them past 1.7,
> > since we're retaining syncdb support. However, if it's crazy complicated,
> > it's likely not worth it.
> >
> > Andrew
> >
> > On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic
> > 
> >
> > wrote:
> > > I have initially created the ticket
> > > https://code.djangoproject.com/ticket/25618 which addressed the bug
> that
> > > would occur if south migrations somehow ended up being still present in
> > > the migrations module.
> > >
> > > According to a report in:
> > > https://code.djangoproject.com/ticket/25618#comment:7, this seems to
> > >
> > > break certain third party apps, in particular:
> > > * non-upgraded apps that retained south migrations in the
> migrations
> > >
> > > module but have not introduced Django migrations. An example of such an
> > > app is `django-extensions`
> > >
> > > Personally, I think, these apps haven't really supported Django past
> > > Django 1.6.x and if they claimed they did, it was a misconception on
> > > their part.
> > >
> > >
> > > However, in order not to break any apps that might have done this, I
> > > created a new pull request, that fixes this problem in a way that will
> > > not cause this issue.
> > >
> > >
> > > I wanted to check what people thought here regarding whether this
> should
> > > be incorporated or not?
> > > Should we make those apps fail and have them fully upgrade to support
> > > 1.7+, or should we address this and let them silently keep the south
> > > migrations?
> > >
> > > --
> > > 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/99820cef-4404-40aa-97
> > > f8-4d3acace0a3b%40googlegroups.com
> > > <
> https://groups.google.com/d/msgid/django-developers/99820cef-4404-40aa-
> > > 97f8-4d3acace0a3b%
> 40googlegroups.com?utm_medium=email_source=footer>
> > > .
> > > 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/CAFwN1uoKv8UuZj0qwsQkJMom9pOSVaKKNzTpMnO31Fp5jtMW0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: An issue with Django 1.8.6 support for south migrations

[Shai Berger]

No, I think we can't do this generically.

If an app ships (South) migrations, we cannot assume that syncdb is an 
adequate replacement; the migrations may include data-migrations which create 
records the app needs. We could in general do something like, try to verify 
that there are no data migrations (this is easier with South migrations than 
with Django migrations), or ask the user for confirmation, or add a "ignore-
south-migrations" setting to list the relevant apps, or find some other way for 
the user to tell us that syncdb is ok for this app, but IMO that takes us a 
step beyond Andrew's "fix is easy".

Shai.


On Saturday 07 November 2015 12:13:02 Andrew Godwin wrote:
> I think if the fix is easy, we should continue to support them past 1.7,
> since we're retaining syncdb support. However, if it's crazy complicated,
> it's likely not worth it.
> 
> Andrew
> 
> On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic
> 
> 
> wrote:
> > I have initially created the ticket
> > https://code.djangoproject.com/ticket/25618 which addressed the bug that
> > would occur if south migrations somehow ended up being still present in
> > the migrations module.
> > 
> > According to a report in:
> > https://code.djangoproject.com/ticket/25618#comment:7, this seems to
> > 
> > break certain third party apps, in particular:
> > * non-upgraded apps that retained south migrations in the migrations
> > 
> > module but have not introduced Django migrations. An example of such an
> > app is `django-extensions`
> > 
> > Personally, I think, these apps haven't really supported Django past
> > Django 1.6.x and if they claimed they did, it was a misconception on
> > their part.
> > 
> > 
> > However, in order not to break any apps that might have done this, I
> > created a new pull request, that fixes this problem in a way that will
> > not cause this issue.
> > 
> > 
> > I wanted to check what people thought here regarding whether this should
> > be incorporated or not?
> > Should we make those apps fail and have them fully upgrade to support
> > 1.7+, or should we address this and let them silently keep the south
> > migrations?
> > 
> > --
> > 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/99820cef-4404-40aa-97
> > f8-4d3acace0a3b%40googlegroups.com
> >  > 97f8-4d3acace0a3b%40googlegroups.com?utm_medium=email_source=footer>
> > .
> > For more options, visit https://groups.google.com/d/optout.

Re: An issue with Django 1.8.6 support for south migrations

[Andrew Godwin]

I think if the fix is easy, we should continue to support them past 1.7,
since we're retaining syncdb support. However, if it's crazy complicated,
it's likely not worth it.

Andrew

On Wed, Nov 4, 2015 at 11:59 PM, David Filipovic 
wrote:

> I have initially created the ticket
> https://code.djangoproject.com/ticket/25618 which addressed the bug that
> would occur if south migrations somehow ended up being still present in the
> migrations module.
>
> According to a report in:
> https://code.djangoproject.com/ticket/25618#comment:7, this seems to
> break certain third party apps, in particular:
>
> * non-upgraded apps that retained south migrations in the migrations
> module but have not introduced Django migrations. An example of such an app
> is `django-extensions`
>
> Personally, I think, these apps haven't really supported Django past
> Django 1.6.x and if they claimed they did, it was a misconception on their
> part.
>
>
> However, in order not to break any apps that might have done this, I
> created a new pull request, that fixes this problem in a way that will not
> cause this issue.
>
>
> I wanted to check what people thought here regarding whether this should
> be incorporated or not?
> Should we make those apps fail and have them fully upgrade to support
> 1.7+, or should we address this and let them silently keep the south
> migrations?
>
> --
> 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/99820cef-4404-40aa-97f8-4d3acace0a3b%40googlegroups.com
> 
> .
> 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/CAFwN1uoqaE3PhVVDZifYbuaehWt%2B7fruBSCA%2BTq2yb1d-OV6gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: feature request - use logging in WSGIRequestHandler

[charettes]

FWI a new ticket[1] with what looks like a sane implementation to add this 
level of logging to the runserver command has been created.

I'll make sure to copy all the concerns raised by Russ over there and you 
might want to chime in the review process.

Simon

[1] https://code.djangoproject.com/ticket/25684

Le jeudi 29 mai 2014 16:38:06 UTC+2, Tino de Bruijn a écrit :
>
>
> On Thu, May 29, 2014 at 3:40 AM, Russell Keith-Magee <
> rus...@keith-magee.com > wrote:
>
>> However, there's a cost - we'd be adding the requirement for a logging 
>> configuration for something that is only ever used during development. So 
>> we'd end up complicating the process of deploying the devserver, which is 
>> one of those things that is supposed to Just Work™ out of the box.
>>
>> I *think* this would also mean losing the colorisation of devserver 
>> messages, and for me, colorisation of output of the devserver is a higher 
>> priority than the need to filter specific lines out of devserver output 
>> (don't quote me on this one though -- it might be possible to preserve 
>> colorisation. Some experimentation may be required).
>>
>
> Isn't this easy to set up with defaults for logging? Like we already do 
> for `django.request` and `django.security`[1]?
>
> And it appears colouring log messages is possible with a custom formatter 
> [2].
>
> +1 from me to have more control over the output of the devserver.
>
>
> Tino
>
> [1] 
> https://github.com/django/django/blob/778ce245dd466bce1b19f89e52cf9ed8f1b46513/django/utils/log.py
> [2] 
> http://stackoverflow.com/questions/384076/how-can-i-color-python-logging-output
>

-- 
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/602a9efc-cfd3-4063-94b5-a3a8e8bdc28d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.