Channels delay server in development enviromnent

[Václav Řehák]

Hi,

one of the things I like about channels is how simply it fits into 
development workflow with runserver. I remember how painful it was to run 
celery on my laptop with all the rabbitmq, worker and celery beat 
processes. However, I now ran into usecase requiring the use of the delay 
server and it seems to me I cannot use it in the simple setup with InMemory 
backend as I need to have rundelay as separate process (or am I missing 
something?).

Is there any reason why channel's runserver management command does not 
include delay server thread in the same way it has the WorkerThread?

Vaclav

-- 
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/f4031868-cf1d-4149-b63a-ca98da86c788%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Channels delay server in development enviromnent

[Andrew Godwin]

Hi Vaclav,

This is because there's only so much we can pack into runserver; when you
develop with Celery, for example, you would probably need to run Celery
unless you turn ALWAYS_EAGER on (and then not actually see any potential
race conditions).

If you don't want to run Redis locally, you can use the asgi_ipc layer (
https://github.com/django/asgi_ipc) which only works between processes on
the same machine, but doesn't require any extra processes to run. It should
get around 5,000 - 10,000 messages/second throughput on a normal laptop,
which should be plenty for your use case.

If you switch to the IPC layer (or the Redis layer), you can still use
"runserver" and then just launch an extra delay server, and all the
components will talk to each other.

Andrew

On Wed, May 24, 2017 at 5:27 AM, Václav Řehák  wrote:

> Hi,
>
> one of the things I like about channels is how simply it fits into
> development workflow with runserver. I remember how painful it was to run
> celery on my laptop with all the rabbitmq, worker and celery beat
> processes. However, I now ran into usecase requiring the use of the delay
> server and it seems to me I cannot use it in the simple setup with InMemory
> backend as I need to have rundelay as separate process (or am I missing
> something?).
>
> Is there any reason why channel's runserver management command does not
> include delay server thread in the same way it has the WorkerThread?
>
> Vaclav
>
> --
> 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/f4031868-cf1d-4149-b63a-
> ca98da86c788%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/CAFwN1uo-KxpQMNDMWv9HHcCzppz8bysyRnTg73gPrOvDjPrA_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Integrate dj-database-url into Django

[Kenneth Reitz]

dj-database-url gives Django developers two main things: 

1. the ability to represent their database settings via a string (a-la 
sqlalchemy); very useful for environmnent variables and 12factor apps.
2. it will automatically use the DATABASE_URL environment variable, if present.

I'm not sure if #2 is appropriate for Django Core (but it would be nice, as 
Gunicorn supports both PORT and WEB_CONCURRENCY), but I know #1 is perfect. 

This plan has previously been discussed (at a conference, DjangoCon EU in 
Zurich, long ago) and approved by JKM, before his role at Heroku, if that is 
helpful information. 

I think this change would vastly improve the usability of Django, and would be 
an excellent and simple move for the project.

Many thanks for your consideration. <3

--
Kenneth Reitz

https://code.djangoproject.com/ticket/28236

-- 
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/057ced98-4471-4939-960b-900ec39f54b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Florian Apolloner]

Hi Kenneth,

I think there are a few things to consider before we can merge/reuse 
dj-database-url.

 * How are third party backends going to fit into this scheme?
 * What about other options like CACHES which very much suffers from the 
same problem.

Cheers,
Florian

-- 
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/e28b5354-201c-41d0-9b7d-aadeb0024200%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Kenneth Reitz]

I don't think the code will be able to be re-used as much as the 
idea/ux/functionality that it provides. 

I can imagine any backend being able to convert from a url string with some 
methods (e.g. `detect_url` (bool return) and `parse_url` (settings dict return 
type).)

Perhaps the same scheme could be applied to caches as well. 

-- 
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/aba85896-0271-4358-aba4-c2e4cab186b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Kenneth Reitz]

Ah, I see what you're saying about third-party backends. 

I imagine that you'd have to be able to merge a url string with a settings dict 
(one overrides the other). This is how usage of that functionality is manually 
provided in 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/9043e51f-843d-4395-9cb1-9ef138108eb7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Tom Forbes]

My two cents: connection strings/database URI's are a feature I've sorely
missed in Django.

Built-in functionality to convert environment variables like
DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant
DATABASE setting would make some deployment situations a lot simpler.
Currently, unless you use dj-database-uri you have to define a bunch of
ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary
together yourself.

How does this library complex keys like OPTIONS, TEST or DEPENDENCIES?

To help support third part backends: perhaps the scheme portion of the URI
could be either a relative import from django.db.backends or an absolute
import to a third party library? It seems URI schemes can have dots and
underscores in them, so they can be python package paths.

I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but
sqlserver_ado://xyz would resolve to the third party django-mssql engine
via an absolute import.

Not sure how to handle arbitrary extra settings though.

On 24 May 2017 19:05, "Kenneth Reitz"  wrote:

> dj-database-url gives Django developers two main things:
>
> 1. the ability to represent their database settings via a string (a-la
> sqlalchemy); very useful for environmnent variables and 12factor apps.
> 2. it will automatically use the DATABASE_URL environment variable, if
> present.
>
> I'm not sure if #2 is appropriate for Django Core (but it would be nice,
> as Gunicorn supports both PORT and WEB_CONCURRENCY), but I know #1 is
> perfect.
>
> This plan has previously been discussed (at a conference, DjangoCon EU in
> Zurich, long ago) and approved by JKM, before his role at Heroku, if that
> is helpful information.
>
> I think this change would vastly improve the usability of Django, and
> would be an excellent and simple move for the project.
>
> Many thanks for your consideration. <3
>
> --
> Kenneth Reitz
>
> https://code.djangoproject.com/ticket/28236
>
> --
> 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/ms
> gid/django-developers/057ced98-4471-4939-960b-900ec39f54b7%4
> 0googlegroups.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/CAFNZOJPogT4y-E4v5giF-6ajbQ6PSpZvpAPZO0BzK%2BLT9uL1xA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: migration lock file implementation

[jian]

To elaborate on this feature request:

When working on a Django project with other people, a common issue is 
unintentionally creating conflicting migrations. These happen silently if 
two developers create and merge migrations in parallel. It's not clear 
there is a problem until after the second migration is merged. With this 
patch, the second migration will be prevented from merging by the VCS due 
to a merge conflict in the lock file.

A documented example of a team that uses something like this in production 
can be found at the Zenefits engineering blog 

.

Do you think that this is a useful feature to have in Django? And if so, 
does the proposed patch 
 
suffice?

-Jian

On Wednesday, May 17, 2017 at 1:30:41 PM UTC-7, Jian Li wrote:
>
> Hi!
>
> This is an idea that has been around for a while, and has been implemented 
> by various organizations running Django: using lock files to prevent 
> migration conflicts.
>
> I recently implemented something for our Django project at work. Here is a 
> cleaned-up version:
>
>
> https://github.com/django/django/compare/master...jianli:migration-lock-file
>
> Hopefully this is useful enough to be merged upstream. Please let me know 
> what you think, and keep up the amazing work!
>
> -Jian
>

-- 
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/98310105-15e4-473f-acab-e9e7b0427250%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: migration lock file implementation

[Andrew Godwin]

I am personally unsure about this - it's extra overhead for smaller Django
sites, and something that larger teams could easily adopt themselves. I
think it might make more sense as a third-party app that plugs in?

Andrew

On Wed, May 24, 2017 at 12:39 PM,  wrote:

> To elaborate on this feature request:
>
> When working on a Django project with other people, a common issue is
> unintentionally creating conflicting migrations. These happen silently if
> two developers create and merge migrations in parallel. It's not clear
> there is a problem until after the second migration is merged. With this
> patch, the second migration will be prevented from merging by the VCS due
> to a merge conflict in the lock file.
>
> A documented example of a team that uses something like this in production
> can be found at the Zenefits engineering blog
> 
> .
>
> Do you think that this is a useful feature to have in Django? And if so,
> does the proposed patch
> 
> suffice?
>
> -Jian
>
> On Wednesday, May 17, 2017 at 1:30:41 PM UTC-7, Jian Li wrote:
>>
>> Hi!
>>
>> This is an idea that has been around for a while, and has been
>> implemented by various organizations running Django: using lock files to
>> prevent migration conflicts.
>>
>> I recently implemented something for our Django project at work. Here is
>> a cleaned-up version:
>>
>> https://github.com/django/django/compare/master...jianli:
>> migration-lock-file
>>
>> Hopefully this is useful enough to be merged upstream. Please let me know
>> what you think, and keep up the amazing work!
>>
>> -Jian
>>
> --
> 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/98310105-15e4-473f-acab-
> e9e7b0427250%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/CAFwN1ure5A%3D53%2BuGROkt0%2B8NLWg0p_rVBUq4uFYNQa%2Bs8ALyMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: migration lock file implementation

[Florian Apolloner]

On Wednesday, May 24, 2017 at 9:42:20 PM UTC+2, Andrew Godwin wrote:
>
> I am personally unsure about this - it's extra overhead for smaller Django 
> sites, and something that larger teams could easily adopt themselves.
>

Yeah, I do not see an immediate need for this either. 

-- 
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/522df540-899e-4c18-a101-d14a9f6535d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Referrer Policy Delivery, Django shouldn't do strict referrer check anymore?

[Flávio Junior]

After two years, made a PR for this during PyCon 
sprints: https://github.com/django/django/pull/8546 🍾
Em sábado, 5 de dezembro de 2015 04:31:12 UTC-8, Collin Anderson escreveu:
>
> Basically, the origin check would only be useful for safari (in this 
> case). Everywhere else we'd still need to rely on the referrer header.
>
> On Sat, Dec 5, 2015 at 3:42 AM, Florian Apolloner  > wrote:
>
>>
>>
>> On Friday, December 4, 2015 at 8:03:45 PM UTC+1, Flávio Junior wrote:
>>>
>>> I can create a ticket suggesting Django to check Origin header before 
>>> checking Referer. Or do you want to create that Collin?
>>>
>>
>> I think Firxfox does not send the origin header ever yet, do you have any 
>> docs on that (Aside from CORS with Ajax from the looks of it)
>>
>> -- 
>> 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/1cb9d411-8247-4e93-8120-5d043869c001%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/f4046f53-3802-41eb-a903-60e5dcc8809f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.