Re: Form field labels change proposal

[Sven R. Kunze]

Good evening everybody. :) I would like to reference this 
ticket: https://code.djangoproject.com/ticket/26497#comment:11

It appears we stumbled over this issue as well while designing a new model 
form. Quoting my comment from the ticket:


Would it make sense to separate concepts here?

1) *user-defined* verbose_name: Django should not touch it
2) *auto-generated* verbose_name: Django generates the verbose_name from 
the field's name


In both cases, once the label of a form field is set, Django should only 
touch it (except on the designers behalf).

*Deprecation phase*:
a) make global capitalization optional via settings (or form variable) with 
True as default for status quo.
b) auto-generated verbose_names are generated using a format string which 
can also be specified by a settings variable (or form variable). Default 
should result in current output (with the capitalization)
c) disable global capitalization by default


Does this makes sense?

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/94da855b-c159-4c17-a24f-16f843096ae7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django template 'if ... is' feature design

[Sven R. Kunze]

Good evening everybody. That's my first post here, so let's how this works. 
:)

This particular discussion caught my sight as it might introduce something 
really "low-level" functionality into the template engine.


I can contribute here to the "design consideration" that from my experience 
with other (less experienced) developers it that the difference of "is" and 
"==" is not quite easy to explain (as illustrated by this thread as well). 
So, I am not 100% convinced that "is" and "is not" is a valid use-case for 
a template language but I may miss some important piece here.


However, given the docs and tests added in the patch, it seems the intended 
use-case for this kind of feature is to check for "is None", "is not None", 
"is True", "is not True" etc. Would it makes sense to hard-wire those 
specific use-cases instead?

(Admittedly, even those can be implemented using "==".)

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e5471b6-2e0a-4098-8056-53787ba75b83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Carl Meyer]

Hi James et al,

In general, I like the idea of adding a helper to Django to read
settings from the environment. I think this helper should be kept as
simple and non-magical as is reasonable. Thus:

- I'm in favor of a flexible helper function that can be manually used
in a settings file to read an explicitly-named env var and coerce it
using any arbitrary callable (that gives enough power to "coerce" using
something as simple as `int` or something as complex as
`parse_database_url` that turns a DSN string into a Django db dict),
with some handling of defaults. Below I give some usage examples of the
function I use for that, and link to its code.

- I'm opposed to anything more magical than that, e.g. anything that
tries to set up an all-dancing automatic mapping or translation between
env var names and setting names, or tries to enforce some particular env
var prefix. The minor gains in conciseness with this kind of thing
aren't nearly worth the losses in flexibility in how you construct your
settings file or name your env vars.

- I'm also opposed to conflating the issue of reading env vars with
orthogonal stuff like class-based settings or patterns for using
multiple settings files.

More comments (and sample code) below:

On 04/11/2016 12:26 PM, Aymeric Augustin wrote:
>> On 11 Apr 2016, at 19:39, Curtis Maloney  wrote:
>>
>> 1. All env vars can have a fallback value (the method in my case)
>> 2. You can mark an env var as not having a fallback value, and it will raise 
>> an error at start up if not set.
> 
> There’s an additional complexity here.
> 
> Usually, it’s best for settings read from environment variables:
> 
> a. To use a default value in dev, even if that means a small degradation in
> functionality. This allows developers to start working on the project without
> adding dozens of exports to their $VIRTUAL_ENV/bin/postactivate, and to add
> just the values they need when they work on specific parts like integrations
> with third-party systems.
> 
> b. To crash if no value is provided in prod, in order to catch configuration
> errors upfront.
> 
> One might think of switching the behavior depending on settings.DEBUG, but
> that won't work because the switch is required to load settings properly.

I totally agree with all this. My projects have a separate MODE setting
which is either 'dev' or 'prod', and I use a utility to read settings
from the environment which supports variable defaults (or lack of
default) by mode, exactly as you outline above. Specifically, it works
like this:


env = EnvParser('PRJ_MODE')

SECRET_KEY = env('PRJ_SECRET_KEY', default={'dev': 'dev-secret'})

The effect of this is that the mode ('dev' or 'prod') will be read from
the `PRJ_MODE` env var (usually `PRJ` would be a short code specific to
the project name). Then if the mode is 'dev', no `PRJ_SECRET_KEY` env
var is required, and 'dev-secret' will be used as the default. But if
the mode is 'prod', the server will fail to start up unless
`PRJ_SECRET_KEY` is found in the environment.

I wrote this to allow for any number of arbitrarily-named modes, but in
practice I've never used anything but 'dev' and 'prod' (staging and demo
sites are generally set up as 'prod'). Hardcoding to those two modes
would perhaps allow a nicer syntax for specifying defaults, by using
separate kwargs instead of the dict.

Anyway, FWIW, here's the code I use:
https://gist.github.com/carljm/69b8e351dac87f4c3f5b440632727fdb

Carl

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/570EA4C6.6080700%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Reopening of Ticket "list_display does not allow functions of referenced objects (#5863)"

[Tim Graham]

I believe https://code.djangoproject.com/ticket/10743 is an accepted ticket 
for this (limited to allowing referencing fields, but not methods, of 
related objects.

On Wednesday, April 13, 2016 at 1:54:29 PM UTC-4, Olivier Dalang wrote:
>
> Dear List,
>
> The idea of allowing relations lookups in the list display was proposed in 
> ticket #5863 , but it was 
> closed as wontfix 5 years ago.
>
> The reason it was closed as wontfix is because it's quite easy to achieve 
> exactly the same result with a method on the ModelAdmin.
>
> However, that workaround is much more verbose, and makes the code much 
> less readable. And I'm pretty sure I'm not the only one to use this in 
> almost all ModelAdmins.
>
> What is your opinion about reopening the ticket ?
>
> Compare the suggested syntax :
>
> class BookAdmin(admin.ModelAdmin):
>> list_display = ('title','author__name')
>
>
> vs the current syntax :
>
> class BookAdmin(admin.ModelAdmin):
>> list_display = ('title','authorname')
>> def authorname(self,obj):
>> return obj.author.name if obj.author else '-'
>> author_name.short_description = 'name'
>> author_name.admin_order_field = 'author__name'
>
>
>
> Thanks ! 
>
> Olivier
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8211926-6e53-4f46-a200-3a5eecb023a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reopening of Ticket "list_display does not allow functions of referenced objects (#5863)"

[Olivier Dalang]

Dear List,

The idea of allowing relations lookups in the list display was proposed in
ticket #5863 , but it was
closed as wontfix 5 years ago.

The reason it was closed as wontfix is because it's quite easy to achieve
exactly the same result with a method on the ModelAdmin.

However, that workaround is much more verbose, and makes the code much less
readable. And I'm pretty sure I'm not the only one to use this in almost
all ModelAdmins.

What is your opinion about reopening the ticket ?

Compare the suggested syntax :

class BookAdmin(admin.ModelAdmin):
> list_display = ('title','author__name')


vs the current syntax :

class BookAdmin(admin.ModelAdmin):
> list_display = ('title','authorname')
> def authorname(self,obj):
> return obj.author.name if obj.author else '-'
> author_name.short_description = 'name'
> author_name.admin_order_field = 'author__name'



Thanks !

Olivier

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAExk7p0sn%3D7j7LQJf3ALOhYo5uZgOdGGb_ycZKX5vYpd-OnPuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Form field labels change proposal

[Sergei Maertens]

Thanks for these specific use cases, I'll see if I can come up with some
acceptable solutions in a reasonable time
On Apr 13, 2016 6:47 PM, "Tim Graham"  wrote:

> Took a quick look at djangoproject.com with this change. I noticed we're
> using the label to construct an input placeholder [0]. I think adapting
> that for this change isn't so easy to do in a cross-browser way via CSS [1]
> but we could add capfirst in the code.
>
> The question of a deprecation seems to be whether it's better to ask every
> Django project opt into the new behavior in the next two releases via some
> temporary setting or if we force all projects to adapt their CSS (and
> possibly code, as the example above shows) for Django 1.10. I'm not too
> happy with either path.
>
> I'm not sure about the validation messages. If we stop capitalizing the
> label, the message "%(field_label)s must be unique for" won't start with a
> capital anymore. On the other hand, capitalizing field_label is awkward if
> a custom message that doesn't put field_label at the start of the sentence
> is used.
>
> [0]
> https://github.com/django/djangoproject.com/blob/7fd780c061e4244982ca5bdd914fd004c6fe90af/members/forms.py#L25
> [1] http://stackoverflow.com/a/2610741/5112
>
> On Sunday, January 31, 2016 at 4:30:09 PM UTC-5, Sergei Maertens wrote:
>>
>> I've done the initial work for a patch, assuming a 'hard' change without
>> deprecation path, the branch is here:
>> https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4
>> .
>> Tests should be passing.
>>
>> I've also taken a quick glance at django-admin-tools to check if they do
>> anything special with decapitalizing/capitalizing things, but all seems to
>> be well. Django injects the form css in the block extrastyle within
>> change_form.html. For Grappelli/django-xadmin that block is present, but
>> Grappelli overrides change_form.html, so that would probably need updating.
>> I haven't looked at any other admin-theme packages, but the change would be
>> trivial for them as well - providing a proper documentation notion.
>>
>> The only things so far I'm not really sure of are:
>>
>>- Is deprecation required or not (input needed from other core devs I
>>presume)
>>- what with the validation error messages: as it stands, field labels
>>are capitalized at the moment, and they're not in a  tag. Examples
>>can be found
>>in: django.db.models.base.Model.(date_error_message|unique_error_message)
>>
>> In the tests I also noticed that there are cases where the label itself
>> is not wrapped in a  tag
>> (django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).
>>
>> On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>>>
>>> Looks easy enough. I was going to write, "Seems to me that there's more
>>> complexity in a deprecation path that requires a temporary opt-in setting
>>> rather than simply making the backwards incompatible change. Unless I
>>> missed something, adding CSS like that shouldn't cause problems for any
>>> apps maintaining compatibility with older versions of Django." but then I
>>> thought of a different case where it could be trickier to upgrade:
>>> developers who are specifying label='lower string' in some places to
>>> workaround the current behavior (but still want uppercased labels
>>> everywhere else). I guess the solution would be to use the text-transform
>>> rule you mentioned and another CSS rule targeting all labels IDs that you
>>> want to remain lowercased.
>>>
>>> I'd like other opinions about whether or not a deprecation seems helpful
>>> for this. Personally, I'd rather just fix my CSS when upgrading rather than
>>> fix my CSS *and* add a setting for a few Django versions to silence the
>>> deprecation. I guess some people might like a few Django versions to update
>>> their CSS though (also we promised to try to provide fairly seamless
>>> upgrades from one LTS to the next).
>>>
>>> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:

 In
 https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
 ,
 after
 label {
font-weight: normal;
color:#666;
font-size:13px;
 }

 you would add
 label::first-letter {
text-transform: capitalize;
 }

 (see https://css-tricks.com/almanac/selectors/f/first-letter/)

 text-transform: capitalize on the label itself would capitalize all
 words, which is not wanted. The ::first-letter pseudo-selector is 

Re: Form field labels change proposal

[Tim Graham]

Took a quick look at djangoproject.com with this change. I noticed we're 
using the label to construct an input placeholder [0]. I think adapting 
that for this change isn't so easy to do in a cross-browser way via CSS [1] 
but we could add capfirst in the code.

The question of a deprecation seems to be whether it's better to ask every 
Django project opt into the new behavior in the next two releases via some 
temporary setting or if we force all projects to adapt their CSS (and 
possibly code, as the example above shows) for Django 1.10. I'm not too 
happy with either path.

I'm not sure about the validation messages. If we stop capitalizing the 
label, the message "%(field_label)s must be unique for" won't start with a 
capital anymore. On the other hand, capitalizing field_label is awkward if 
a custom message that doesn't put field_label at the start of the sentence 
is used.

[0] 
https://github.com/django/djangoproject.com/blob/7fd780c061e4244982ca5bdd914fd004c6fe90af/members/forms.py#L25
[1] http://stackoverflow.com/a/2610741/5112

On Sunday, January 31, 2016 at 4:30:09 PM UTC-5, Sergei Maertens wrote:
>
> I've done the initial work for a patch, assuming a 'hard' change without 
> deprecation path, the branch is here: 
> https://github.com/sergei-maertens/django/commit/2f3c1d8dd56522dc69448ec20aac28d4ddc70ac4
>  
> .
>  
> Tests should be passing.
>
> I've also taken a quick glance at django-admin-tools to check if they do 
> anything special with decapitalizing/capitalizing things, but all seems to 
> be well. Django injects the form css in the block extrastyle within 
> change_form.html. For Grappelli/django-xadmin that block is present, but 
> Grappelli overrides change_form.html, so that would probably need updating. 
> I haven't looked at any other admin-theme packages, but the change would be 
> trivial for them as well - providing a proper documentation notion.
>
> The only things so far I'm not really sure of are:
>
>- Is deprecation required or not (input needed from other core devs I 
>presume)
>- what with the validation error messages: as it stands, field labels 
>are capitalized at the moment, and they're not in a  tag. Examples 
>can be found 
>in: django.db.models.base.Model.(date_error_message|unique_error_message)
>
> In the tests I also noticed that there are cases where the label itself is 
> not wrapped in a  tag 
> (django.tests.forms_tests.tests.test_forms.FormsTestCase.test_templates_with_forms).
>
> On Friday, November 20, 2015 at 8:31:55 PM UTC+1, Tim Graham wrote:
>>
>> Looks easy enough. I was going to write, "Seems to me that there's more 
>> complexity in a deprecation path that requires a temporary opt-in setting 
>> rather than simply making the backwards incompatible change. Unless I 
>> missed something, adding CSS like that shouldn't cause problems for any 
>> apps maintaining compatibility with older versions of Django." but then I 
>> thought of a different case where it could be trickier to upgrade: 
>> developers who are specifying label='lower string' in some places to 
>> workaround the current behavior (but still want uppercased labels 
>> everywhere else). I guess the solution would be to use the text-transform 
>> rule you mentioned and another CSS rule targeting all labels IDs that you 
>> want to remain lowercased.
>>
>> I'd like other opinions about whether or not a deprecation seems helpful 
>> for this. Personally, I'd rather just fix my CSS when upgrading rather than 
>> fix my CSS *and* add a setting for a few Django versions to silence the 
>> deprecation. I guess some people might like a few Django versions to update 
>> their CSS though (also we promised to try to provide fairly seamless 
>> upgrades from one LTS to the next).
>>
>> On Friday, November 20, 2015 at 11:38:53 AM UTC-5, Sergei Maertens wrote:
>>>
>>> In 
>>> https://github.com/django/django/blob/master/django/contrib/admin/static/admin/css/forms.css#L31
>>>  
>>> ,
>>>  
>>> after
>>> label {
>>>font-weight: normal;
>>>color:#666;
>>>font-size:13px;
>>> }
>>>
>>> you would add
>>> label::first-letter {
>>>text-transform: capitalize;
>>> }
>>>
>>> (see https://css-tricks.com/almanac/selectors/f/first-letter/)
>>>
>>> text-transform: capitalize on the label itself would capitalize all 
>>> words, which is not wanted. The ::first-letter pseudo-selector is supported 
>>> on all browsers, for IE 8 and lower you need a sigle colon instead of a 
>>> double colon.
>>>
>>>
>>> On Thursday, November 19, 2015 at 11:23:48 PM UTC+1, Tim Graham wrote:

 I'd like to see the admin's CSS 

Re: Land Information System in Django

[Tim Graham]

The django-developers mailing list is for the development of Django itself. 
Please use django-users for questions like this.

Did you find out about this mailing list from somewhere where this 
distinction isn't clear?

On Wednesday, April 13, 2016 at 8:36:49 AM UTC-4, Wanjohi Kibui wrote:
>
> Hello Claude. Thank you for the response. The section that bothers me is 
> not the GIS part .Its more of the django section.If I allow users to access 
> the services in the LIMS, it means they will be filling in some forms and 
> submitting the forms to the admin.My issues arises when I want to track the 
> state of the document and the actions of each department on the submitted 
> document from start to end.This is where I am a bit stuck.This is where I 
> need some guidance.Hope you now understand my issue.Thank you
>
> On Tuesday, April 12, 2016 at 9:55:10 PM UTC+3, Claude Paroz wrote:
>>
>> Le mardi 12 avril 2016 20:28:12 UTC+2, Wanjohi Kibui a écrit :
>>>
>>> Hello.Am working on a LIS in django and having difficulties on how to 
>>> handle land services applications by clients and how they are handled in 
>>> the system e.g. How its acted upon by many department each having a role to 
>>> play in the document and changing status from start to completion. Anyone 
>>> who could have done this before to give a green light for my issue 
>>> please?Would be so thankful for the help.
>>>
>>
>> Hi Wanjohi,
>>
>> I find your question a bit vague, it's a bit difficult to answer without 
>> a more precise question. Moreover, if the question is GIS-specific, the 
>> GeoDjango mailing list might be more appropriate.
>>
>> Cheers,
>>
>> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/745abd9c-cd62-450d-9e49-f643255b57f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Land Information System in Django

[Wanjohi Kibui]

Hello Claude. Thank you for the response. The section that bothers me is 
not the GIS part .Its more of the django section.If I allow users to access 
the services in the LIMS, it means they will be filling in some forms and 
submitting the forms to the admin.My issues arises when I want to track the 
state of the document and the actions of each department on the submitted 
document from start to end.This is where I am a bit stuck.This is where I 
need some guidance.Hope you now understand my issue.Thank you

On Tuesday, April 12, 2016 at 9:55:10 PM UTC+3, Claude Paroz wrote:
>
> Le mardi 12 avril 2016 20:28:12 UTC+2, Wanjohi Kibui a écrit :
>>
>> Hello.Am working on a LIS in django and having difficulties on how to 
>> handle land services applications by clients and how they are handled in 
>> the system e.g. How its acted upon by many department each having a role to 
>> play in the document and changing status from start to completion. Anyone 
>> who could have done this before to give a green light for my issue 
>> please?Would be so thankful for the help.
>>
>
> Hi Wanjohi,
>
> I find your question a bit vague, it's a bit difficult to answer without a 
> more precise question. Moreover, if the question is GIS-specific, the 
> GeoDjango mailing list might be more appropriate.
>
> Cheers,
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cac6f00c-0c82-47ed-9b59-2c5fefb2756a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Land Information System in Django

[Wanjohi Kibui]

Thank you for the reply.I do understand it's a difficult question but as I 
described it,not really sure how to put it.I have no issues with the GIS 
part.Am okay in that.The part that bothers me is when a client applies for a 
service by submitting a form, it's acted upon by different departments from 
start to completion of e.g. Sale of a parcel which is purely django.My issue 
mainly comes in how to mark the status of the document during the process and 
how to manage each action of a department in the document by for example having 
editable fields that are only restricted to certain users or department s and 
after each action change its status in the system automatically.Hope this 
explains better.thanks

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6cf8c1c7-8b60-47e1-89c1-706d16001ee6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Enforcing a max size for form field values read into memory (review/determination of next steps needed)

[Tim Graham]

This was deferred from 1.9 as it was still under review around the alpha 
deadline. I've updated the patch to merge cleanly and am asking for anyone 
interested in reviewing it to do so in the next month (ideally well before 
the May 16 alpha release date) so we can get it into 1.10. Thanks!

https://github.com/django/django/pull/6447

On Wednesday, September 9, 2015 at 8:22:23 PM UTC-4, Tim Graham wrote:
>
> Hi, I think I will be able to make good on my promise to give all the 
> tickets that were in the review queue on last Friday a review for 1.9, 
> except for this one...
>
> https://code.djangoproject.com/ticket/21231
> https://github.com/django/django/pull/3852
>
> Mostly I am wondering if there any other frameworks that do a similar 
> thing so we can at least validate that the design makes sense. 
> 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/05aba726-8771-4746-9e64-40425cd263a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[aRkadeFR]

I like the try to move things towards this kind of settings more 
PaaS-friendly.


As a Django user, I'd like to see 'DSN' or 'URL' for the database as a 
built-in in Django. I don't

mind setting it in the dict as so:
```
DATABASES = {
'default': {
'DSN': 'postgres://user:password@ip:port/name_db',
}
}
```

and I use the same configuration layout as aymeric augustin, with most 
of the env name prefix

with ``DJANGO_``.

I'm not exactly a PaaS user, but I package my code with dh-virtualenv 
under .deb which has

some similar constraints as the PaaS out there.


On 04/11/2016 08:33 AM, James Bennett wrote:
Apologies for how late in the process this is; job hunt + moving 
cross-country ate a lot of my time.


At Django Under the Hood I proposed that for Django 1.10 we try to 
find some common best practices for deploying Django on popular 
platform-as-a-service (PaaS) solutions, and building support for them 
into Django. The biggest one of these is probably having the ability 
to read configuration from environment variables instead of 
hard-coding things into settings files.


At the very least I'd like to propose (assuming Kenneth is on board 
with it) integrating dj-database-url[1] or something like it directly 
into Django, so that there's no longer a third-party dependency for 
reading the database configuration from an environment variable. 
Whether this is just porting dj-database-url itself in, or making the 
DATABASES setting understand URLs, I'm unsure of yet and would be 
interested to hear feedback on. Either way I'm willing to put in the 
time to develop the patch.


More generally, I'd like to see Django grow helpers for specifying 
settings that should be read from environment variables, and which 
environment variables to use (the email settings are another common 
case, as is anything that requires an API key to access).


There are a few ways to design this. One option would be just a 
minimal wrapper around os.getenv, perhaps taking an optional type or 
type-coercing function, so that it would be possible in a settings 
file to do:


SECRET_NUMBER_SETTING = env_setting('SECRET_NUMBER', int)

However, this is not much better than the current practice of calling 
os.getenv. A better solution might be the ability to specify a group 
of settings which will be read from the environment, and have Django 
automatically read and set them. For example:


ENV_SETTINGS = [
('SECRET_NUMBER_SETTING', int),
('ACME_API_KEY', str),
('VOLCANO_LAIR_PASSWORD', str),
]

would read the named settings from those environment variables, and 
coerce them to the appropriate types using the function provided.


The main problem with this is that it's really not very elegant. But 
at the moment I can't think of anything better, and so I'd like to 
throw the floor open to ideas on nicer approaches to this. If one 
can't be found, I do think Django 1.10 should at least figure out how 
to handle database config from env since that's such a common use case 
nowadays, but ideally we'd be able to pin down a good API for 
generically pulling configuration from the environment.



[1] https://github.com/kennethreitz/dj-database-url
--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg85fYj0i0ysxJGo2SDesqELMeA%2BtnKJ9cdpqNHmQ%3DX3Pg%40mail.gmail.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/570E0733.5040607%40arkade.info.
For more options, visit https://groups.google.com/d/optout.