Re: Making Django more PaaS-friendly

[Aymeric Augustin]

Hello,

If anything, this discussion shows that people have come up with a wide
variety of customized solutions to meet their use cases. That supports
Django’s historical decision not to be too prescriptive in this area.

I still think James’ proposal is valuable because it will nudge developers
towards best practices when deploying on a PaaS, a path often taken
by those least familiar with deployment best practices in general.

Best regards,

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/B239EA24-C912-4A32-8C04-795B01BD1317%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Marcin Nowak]

Hi all,

On Wednesday, April 13, 2016 at 9:58:18 PM UTC+2, Carl Meyer wrote:
>
> 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: 
>
> This sounds great. Django should not do anything magical and just in one 
way. 
Just give the tool to the developers.

But I would like to say my thoughts about "settings" itself.
They were good (simple) before incuding nested dictionaries.
After switching to dicts the settings handling went harder way.

As a example I can tell about reconfiguring LOGGING for dev/live settings.
We're tuning them via direct changes like 
LOGGING['loggers']['some-logger']['level']='...'
which is very error prone. The flat settings are easier to maintain.

Nested settings are good for framework internals and should stay in that 
form, 
but maybe solution for end users and ENV integration is flattening settings 
again, at the high-level?

Let's imagine something like INI file which is parsed somehow and converted 
to internal settings object.
The INI file has a shallow structure (options grouped in sections), 
can be easily extended / overrided / included (look at Buidout as an 
example),
and ENV keys will be related to flat INI instead of nested settings.py.

Let's consider an example:

[databases]
default.url = postgres+psycopg2://user:pwd@localhost:5432/exampledb
default.engine = django.db.backends.postgres_psycopg2


which can be simply reconfigured by ENV vars like:

DJANGO_DATABASES_DEFAULT_URL="postgres+psycopg2://user:pwd@localhost:5432/exampledb"
DJANGO_DATABASES_DEFAULT_ENGINE="django.db.backends.postgres_psycopg2"

OR add some preprocessing and flexibility:



[databases]
default.url = ${env:SOME-USER-KEY1}
default.engine = ${env:SOME-USER-KEY2}


[env]
SOME_USER_KEY1=a default value for default database URL
SOME_USER_KEY2=a default value for default database engine


where [env] section will by filled automatically by Django from os.environ.

This also gives a possibility to extend settings.ini via development.ini, 
where [databases] can be overridden with developer settings (without env 
access)


Thanks for reading and sorry for my English. I hope you understood the idea.
Marcin

 

-- 
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/6dbaaaca-8de7-49d3-a7b8-df011b94f147%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Usage of DjangoRuntimeWarning

[Tim Graham]

I think warnings.filterwarnings(RuntimeWarning, module="django..") might 
allow filtering without a subclass?

According to the ticket, Carl offered the version of the patch with 
DjangoRuntimeWarning "following design discussion with Russell K-M, Malcolm 
T, Jannis L, and Jeremy Dunck." (in case any of them are reading this and 
remember the discussion from 6 years ago) [0].

[0] https://code.djangoproject.com/ticket/6447#comment:12

On Friday, April 15, 2016 at 2:44:42 PM UTC-4, charettes wrote:
>
> During a review session I noticed the existence of 
> `DjangoRuntimeWarning`[1]
> which was introduced in order to be subclassed to warn about about cache 
> keys
> that are not compatible with Memcache[2].
>
> As our test suite demonstrate subclassing `RuntimeWarning` can be quite 
> useful
> when you want to consider some of them as errors[3] or simply ignore them. 
> I'm
> sure some of you will remember the pesky naive datetime warnings that were
> raised when using the SQLite3 backend with IPython when timezone support 
> was
> introduced.
>
> While reviewing a proposed change where I suggested introducing another
> `DjangoRuntimeWarning` just like we do with the cache key warning Claude 
> noted
> that we should always use such a patten or simply drop it[4] as a quick
> `grep RuntimeWarning django -r` revealed the cache key warning was the only
> occurence of `DjangoRuntimeWarning`.
>
> While I don't think subclassing `DjangoRuntimeWarning` for every internal 
> use of
> `warnings.warn` is required I believe using `DjangoRuntimeWarning` instead 
> of
> `RuntimeWarning` would make sense.
>
> Thoughts?
>
> Simon
>
> [1] 
> https://github.com/django/django/blob/74675a15d04260e8def7303e1d7a1425b6043b6c/django/core/exceptions.py#L13-L14
> [2] 
> https://github.com/django/django/commit/fc26da645aea2361d78cf5a5543214a240d82527
> [3] https://github.com/django/django/blob/master/tests/runtests.py#L25-L26
> [4] 
> https://github.com/django/django/pull/6384/files/49a9a4c522e7733be7dc9d3d3f66a422731898e9#r59893575
>

-- 
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/a412fb59-fda6-487a-a680-6787f36d30d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: NumericListfilter or similar

[Tim Graham]

Does it need to be in Django itself? I'd think probably not, at least to 
start, but if there's something prohibiting that, then let us know.

On Tuesday, April 19, 2016 at 1:19:02 PM UTC-4, John Griebel wrote:
>
> I agree that we need a replacement; the current behaviour isn't all that 
> useful, IMHO. My vote would for choice #2, after all it seems more natural 
> (to me, at least), to think of numbers as a range, especially while 
> searching. Option 1 seems less intuitive for a situation like this. 
>
> +1 from me, especially if we were to go with option 2.
>
> On Tue, Apr 19, 2016 at 10:46 AM, Omer Korner  > wrote:
>
>> This is a proposal for a new ListFilter subclass.
>>
>> Currently, if you add a numeric field to list_filter, Django admin 
>> outputs all possible values of that field using AllValuesFieldListFilter. 
>> This can get ugly very quickly.
>> For example, in my case, I have an application that manages transactions 
>> (orders) from an ecommerce site, and saves the transaction value. I can't 
>> easily filter the values (hundreds of thousands of them).
>>
>> I have two suggestions for a replacement, instead of outputting all 
>> available values for a numeric field:
>>
>>
>>1. Output something similar to what DateFieldListFilter does, eg. "10 
>>or less/more, 15 or less" and so on, depending on real values. 
>>
>>
>>
>> 
>>
>>2. A numeric input. These an be two inputs for a range, or a single 
>>input for a specific value. Looking at the ListFilter code, this would be 
>> a 
>>much more complex change.
>>
>>
>> Happy to hear your thoughts.
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/9ef08349-f6a6-48ed-bc30-5b62072fb749%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/68790d91-2c2b-4cbd-b88e-3b0de99964ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: One Click Django Installer

[Tim Graham]

This mailing list is about the development of Django itself. The 
django-users mailing list would be more appropriate for a message like this.

On Sunday, April 24, 2016 at 11:53:19 AM UTC-4, Ankit Kumar wrote:
>
> Check this video :
>
>
> https://www.youtube.com/watch?v=85P3Qn9Sccs 
> 
>
> Download installer file
>
> https://www.dropbox.com/s/l8t483dqcjh8m75/Django.rar?dl=0
>

-- 
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/45cbf7f8-6e00-41d0-bcba-39d4336f718d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: IntegrityError when cascading delete, and there post_delete that creates a new object.

[Tim Graham]

Hi, sorry but this mailing list isn't a second level support channel if you 
don't get a question answered on django-users.

On Tuesday, April 26, 2016 at 1:14:30 PM UTC-4, Paulo Maciel wrote:
>
> Hi, I have a problem that already published in Django users, but did not 
> find the solution to this. 
> When deleted in cascade and a relationship has a post_delete that creates 
> an entry to a deleted object, an error occurs and the exception does not 
> work.
>
> Please look at this 
> https://groups.google.com/d/msg/django-users/_g6WdN1tUgA/pjjnA00kMAAJ
>

-- 
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/dc0e486b-d3f0-45e4-9451-99d40382cd26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #26481 - Add a "strict mode" for defer()/only()

[Tim Graham]

I guess there's some question about whether or not we need to make changes 
in Django given Anssi's comment, "Overriding Model.refresh_from_db() allows 
raising failure when deferred field is accessed - is this enough for you 
use case?"

On Friday, April 22, 2016 at 7:07:07 AM UTC-4, Fabien SCHWOB wrote:
>
> Hello,
>
> I would like to try to work on the #26481 ticket, and I'm new to the inner 
> workings of Django, but I thinks it's the best way to learn more about it.
>
> Several enhancements / modifications are related to this ticket :
>
> * The first one is adding a strict argument to only() that will raise an 
> AttributeError.
> * The second one is adding option to the DATABASES settings to enable 
> logging/warning (Maybe something like DATABASES[]['STRICT_DEFER_ALERT']). 
> Or maybe using the -W option of Python.
>
> I would like to have opinions about the best API to implement, and to know 
> if nobody is already working on this ticket.
>
> 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/4b7a45c8-5fae-46f7-a8c6-866d7f8f6939%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]

It seems there was request.body checking in previous iterations of the PR 
but it was dropped for reasons that aren't entirely clear to me:
https://github.com/django/django/pull/3852#discussion_r35350372

On Wednesday, April 20, 2016 at 9:30:48 PM UTC-4, Cristiano Coelho wrote:
>
> Hi,
>
> In particular I'm interested in this new setting: DATA_UPLOAD_MAX_MEMORY_SIZE 
> [1]
> that only seems to be checked against mutlparts [2] and url encoded[3] 
> request bodies.
>
> It could be good that this setting is also checked against other types 
> where request.body is read directly, as you can still get the 
> content-length from the body right? Please correct me if I'm wrong, but 
> when in already django code all body data is always loaded in memory except 
> for files and multi-part uploads which are streamed.
> So JSON, XML or even plain text post requests could benefit from the 
> DATA_UPLOAD_MAX_MEMORY_SIZE setting and it could be very convenient for 
> example if an attacker sends a huge json, the python (at least 2.7) 
> json.loads call usually crashes with an out of memory error when the string 
> is too big while still creating a huge RAM spike.
>
>
> [1] 
> https://github.com/django/django/pull/6447/files#diff-ba8335f5987fcd81d41c28cd1879a9bfR291
> [2] 
> https://github.com/django/django/pull/6447/files#diff-ba8335f5987fcd81d41c28cd1879a9bfR291
> [3] 
> https://github.com/django/django/pull/6447/files#diff-0eb6c5000a61126731553169fddb306eR294
>
>
> El martes, 19 de abril de 2016, 13:06:27 (UTC-3), Tom Christie escribió:
>>
>> > If you are using django-rest-framework, how would the fields counter 
>> work?. It would be a shame if only multi part and urlencoded uploads would 
>> have the benefit of these checks, while still allowing json, xml and others 
>> still be "exploited".
>> Note I didn't really read the code changes completely so I'm talking with 
>> almost no knowledge on the proposed change.
>>
>> They wouldn't be respected by anything other than multi-part or 
>> urlencoded requests.
>> Tim's correct in noting that accessing `request.body` or `request.stream` 
>> won't apply these checks (which is for example, what REST framework does).
>>
>> Even so I think this is probably a reasonable approach. We could add 
>> support for respecting these settings in REST framework too, once they 
>> exist.(Although I think we'd have need to have a stricter consideration of 
>> backwards compat wrt. folks POSTing large amounts of JSON data)
>>
>>

-- 
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/b774f45f-dd05-4ddb-9a69-1a33e1843685%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Making Django more PaaS-friendly

[Hanne Moa]

On 12 April 2016 at 05:35, Martin Owens  wrote:
> There is a difference between settings intended by developers to be used by
> other developers /../ And settings used by systems administrators to define
> the environment they are deployed to as well as any deployment specific
> controls.
>
> Django has always mixed the two into one file, and it causes problems. I've
> seen keys and passwords committed to github, extravagant json or os.env
> based solutions with piles of lines of messy code to what I see most which
> is a local_settings.py with a template version which is copied in at runtime
> with sane defaults.

I used to use extravagant json messes[*] but have (on non-PaaS)
switched to having a directory /etc/django-sites.d, which is on the
python path, containing one python package per site on that host:

/etc/django-sites.d/MyProjectConf/sitetype.py

MyProject.settings.sitetype is referenced by wsgi-scripts. It first
star-imports MyProject.settings.base, then star-imports
MyProjectConf.sitetype inside a try/except.

That way I can have have important overrides/option-merging for a
sitetype in version control, and still have
puppet/chef/ansible/whatever control deploy-and-site-specific options
without touching anything inside the source tree.

> I'd be happy to see a canonical decision made for django, but I'd focus on
> "who should be editing this setting" not just what it's for, if it's a
> secret or if it should be different or the same per instance.

A tag in the settings-docs would be a good start, or a check list of
more site dependent settings. Hey, the docs are restructured text; the
tag could generate an extra index, et voila :)


-- 
HM

[*] I *know* why json doesn't survive that spurious comma at the end
of a list/dict, but I like me that comma so much that I no longer use
json for hand-written config in new stuff.

-- 
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/CACQ%3Drrd3GyFgpxkCJkNegnk62EmR1VzVvS5OToeV6Prns4qWeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

IntegrityError when cascading delete, and there post_delete that creates a new object.

[Paulo Maciel]

Hi, I have a problem that already published in Django users, but did not 
find the solution to this. 
When deleted in cascade and a relationship has a post_delete that creates 
an entry to a deleted object, an error occurs and the exception does not 
work.

Please look at this 
https://groups.google.com/d/msg/django-users/_g6WdN1tUgA/pjjnA00kMAAJ

-- 
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/63ab0197-59ea-44c9-b19b-b3f99f1adb55%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Decoupling Permission-Check from Calling the View

[Alasdair Nicol]

I haven't needed to explain why permission has been granted, but I have had 
admins asking me why a user is getting permission denied for a particular 
view. To answer that, you would

1. Get the url
2. Resolve that to a view
3. Look up the view in the correct views.py, and check which permissions 
the permissions_required decorator was using

We managed to automate 1. and 2. but not 3. 

In Django 1.9, the permission_denied view takes the exception as the second 
argument. If the permission_denied decorator included the permission names 
in the message when raising PermissionDenied, we would be able to display 
the list of permissions in the template. Even better, you could show the 
missing permissions, although that would require a larger patch.

Another option would be for the permission_required decorator to set a 
_permissions attribute on the decorated view, containing the list of 
permissions. A custom permission_denied view could then introspect the view.

cheers,
Alasdair

On Tuesday, 26 April 2016 14:17:37 UTC+1, guettli wrote:
>
> I would like to decouple the permission checking in django.
>
> Current draw-back: If you use decorators like  [login_required][1], then 
> you can't know in advance whether a user has the permission to do so or not.
>
> I would like to split this into two steps:
>
>  1. check permissions
>  1. call the view.
>
>
> # Use Case 1: Admin tool
> I want an tool for admins where they can check the access-permissions of 
> users. This requires:
>
>  1. The check must not use the current `request.user` since this is the 
> wrong user object.
>  1. The check must not actually call the view, since this might alter data.
>
> # Use Case 2: Show Link as disabled.
>
> I want to show links as disabled (grayed out and without "href") if a user 
> does not have the permission to see linked page.
>
> # Dream
> Returning a boolean for "ok" and "permission denied" is nice. But the big 
> benefit would be if the admin could get a **reason**.
>
> Example: 
>
>  1. Admin opens "Check Perm Tool"
>  1. He selects a view/URL
>  1. The admin hits "submit"
>
>
> Result:
>
> --
> | User | Allowed | Reason
> --
> | fooadmin |  Yes| is_superuser
> | foouser  |  No | missing permission "view-bar-at-midnight"
> | foobar   |  Yes| User has permission "view-bar-at-midnight"
>
> # Question
> How to get this dream come true?
>
>
>   [1]: 
> https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required
>
>
>
>
>
>
>
>

-- 
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/59576592-4a44-4d91-b6d4-bde192d8a753%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Decoupling Permission-Check from Calling the View

[guettli]

I would like to decouple the permission checking in django.

Current draw-back: If you use decorators like  [login_required][1], then 
you can't know in advance whether a user has the permission to do so or not.

I would like to split this into two steps:

 1. check permissions
 1. call the view.


# Use Case 1: Admin tool
I want an tool for admins where they can check the access-permissions of 
users. This requires:

 1. The check must not use the current `request.user` since this is the 
wrong user object.
 1. The check must not actually call the view, since this might alter data.

# Use Case 2: Show Link as disabled.

I want to show links as disabled (grayed out and without "href") if a user 
does not have the permission to see linked page.

# Dream
Returning a boolean for "ok" and "permission denied" is nice. But the big 
benefit would be if the admin could get a **reason**.

Example: 

 1. Admin opens "Check Perm Tool"
 1. He selects a view/URL
 1. The admin hits "submit"


Result:

--
| User | Allowed | Reason
--
| fooadmin |  Yes| is_superuser
| foouser  |  No | missing permission "view-bar-at-midnight"
| foobar   |  Yes| User has permission "view-bar-at-midnight"

# Question
How to get this dream come true?


  [1]: 
https://docs.djangoproject.com/en/1.9/topics/auth/default/#django.contrib.auth.decorators.login_required







-- 
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/bad970d5-182c-4ad7-9dd9-fb0424291e40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.