Re: Django Integration

[Mark Lavin]

Thank you Russ. I'll reconsider expressing my full thoughts on Channels 
more likely in another thread. For now I do think it's worth addressing 
this issue of benchmarks/performance which keeps being brought up. The 
argument is that since this is optional we don't need to see the benchmarks 
because there won't be any regressions, which is true. However, if it is 
also being said that this is so fundamentally important to Django and 
everyone will use it so it cannot live as an external project and must land 
in 1.10 then I don't think that argument can be made without ensuring there 
are no huge regressions moving an existing application from WSGI to ASGI. 
If nothing else those benchmarks seem important for Django users to make an 
informed choice about WSGI vs ASGI for their deployment. How can we not 
care about how this "fundamental change to Django" might impact performance 
or say that isn't a requirement to even measure, regardless of outcome, 
before its inclusion?

- Mark

On Wednesday, May 4, 2016 at 10:00:15 PM UTC-4, Russell Keith-Magee wrote:
>
> Hi Mark,
>
> On Thu, May 5, 2016 at 8:41 AM, Mark Lavin  > wrote:
>
>> Major features have never been perfect, no, but they have in the past 
>> typically gone through two paths to prove out their design/API/usefulness. 
>> One is as an established and mature third-party app such as messages, 
>> staticfiles, and django-secure. More recently the other has been through 
>> the DEP process: multiple templates (Jinja) and query expressions. Channels 
>> has done neither.
>>
>> Sorry if it seems that I've raised these issues late but I don't feel 
>> like there has been a good place for this discussion since the DEP process 
>> was circumvented. Most of the development for this has been in Andrew's 
>> space. I don't feel welcome to raise a dissenting opinion as a mere lowly 
>> member of the Django community. 
>>
>
> If that’s your perception, then we as a community clearly have a problem 
> that needs to be addressed. 
>
> You’ve been around the Django community since (AFAICT) 2009. You’re a 
> technical director at a well known and well respected Django consultancy. 
> You’ve given talks at DjangoCons. You’ve co-written a book about Django for 
> O’Reilly. If you’re not someone who is in a position to give an informed 
> opinion on issues with Channels, then I don’t know who is. If you feel like 
> you’re on the outer and your opinion is not welcome, then that’s *our* 
> failure, not yours.
>
> I can’t argue with the fact that the DEP process has been circumvented 
> here. I also acknowledge that this would be doubly frustrating given your 
> difficulties shepherding the content negotiation DEP. I don’t think I can 
> give a good answer for why this has been done, other than enthusiasm and 
> momentum overriding a not-entirely-well-established process.
>
> This thread (and email in general) probably isn’t the best place to flesh 
> out the solution to these process issues, but they definitely need to be 
> resolved. Discussion at PyCon and DjangoCon US is definitely called for - 
> I’ll be at both, and I’d definitely be interested in a BOF or similar 
> session to field opinions and thoughts from the community about this 
> process.
>  
>
>> It's pointless for me to continue to elaborate on the things I don't like 
>> about channels as I'm clearly in the minority and it's going to land. All I 
>> can do now is beg for these requirements to be optional.
>>
>
> Talking about channels specifically: This shouldn’t be true at all. 
> There’s certainly some momentum, but the code isn’t in trunk, so it’s not 
> too late. Even if it *was* in trunk - if you could demonstrate that there 
> was a serious problem, I’d support removing it from the codebase.
>
> I will admin that I haven’t been paying *close* attention to Andrew’s work 
> - I’m aware of the broad strokes, and I’ve skimmed some of the design 
> discussions, but I haven’t been keeping close tabs on things. From that 
> (admittedly weak) position, the only counterargument that I’ve heard are 
> performance concerns. 
>
> However, the last thing I heard on this subject was that the “raw WSGI” 
> path was essentially unmodified, so there shouldn’t be any particular 
> performance concerns from adding this to the codebase - just new 
> functionality for targeting websockets. For me, websockets are a big area 
> where Django is currently lacking, and everything I’ve read about Andrew’s 
> proposal has struck me as a reasonable compromise between Django’s need to 
> respond to a technical requirement, while maintaining ease of 
> implementation. 
>
> I take it that this isn’t your opinion. If you’ve got other concerns - be 
> they specific implementation issues, or broader philosophical issues, I’d 
> strongly encourage you to express them. The core team and/or technical 
> board might not agree with you, but we’d be fools to ignore your experience 
> and opinions. At the absolute 

Re: re-thinking middleware

[charettes]

Hi Tim,

I think we should favor displaying a message in accordance with the setting 
the user is using as it will make the transition less confusing. In the 
case of the documented check message I think using the form 
"MIDDLEWARE/MIDDLEWARE_CLASSES" would make it easier to read then 
mentioning the two possible variants. We already alter the document 
messages anyway to account for their dynamic nature.

In the case of the tests I believe both code path should continue to be 
tested. From the top of my head I can't think of an alternative to 
subclasses using @override_settings. I suggest we make the *legacy* tests 
class extend the MIDDLEWARE using test class and not the other way around 
as it will make the MIDDLEWARE_CLASSES code removal clearer.

Simon

Le mercredi 4 mai 2016 19:59:05 UTC-4, Tim Graham a écrit :
>
> I've been working on this and wanted to raise a couple points for 
> discussion.
>
> How should we treat error messages in place like system checks where we 
> have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check 
> can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much effort 
> but should we make the error message "smart" and display the version of the 
> setting that the user is using? Alternatively, we could always reference 
> MIDDLEWARE (the non-deprecated version) or use some variation like 
> "MIDDLEWARE(_CLASSES)" or "MIDDLEWARE/MIDDLEWARE_CLASSES" until the 
> deprecation period ends.
>
> Another point for discussion is whether we need to duplicate a lot of 
> tests so we test that the middleware continue to work with both the 
> old-style MIDDLEWARE_CLASSES and the new style MIDDLEWARE response 
> handling. I guess a subclass of anything that uses 
> @override_settings(MIDDLEWARE=...) that uses 
> @override_settings(MIDDLEWARE_CLASSES=...) might work. Just putting it out 
> there in case anyone has a better idea.
>
> On Monday, January 18, 2016 at 9:20:03 PM UTC-5, Carl Meyer wrote:
>>
>> I've updated DEP 5 with a new round of clarifications and tweaks based on 
>> the most recent feedback: 
>> https://github.com/django/deps/compare/62b0...master
>>
>> 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/eb1cf3f4-c021-40f6-be65-35427b2bf5c5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Russell Keith-Magee]

Hi Mark,

On Thu, May 5, 2016 at 8:41 AM, Mark Lavin  wrote:

> Major features have never been perfect, no, but they have in the past
> typically gone through two paths to prove out their design/API/usefulness.
> One is as an established and mature third-party app such as messages,
> staticfiles, and django-secure. More recently the other has been through
> the DEP process: multiple templates (Jinja) and query expressions. Channels
> has done neither.
>
> Sorry if it seems that I've raised these issues late but I don't feel like
> there has been a good place for this discussion since the DEP process was
> circumvented. Most of the development for this has been in Andrew's space.
> I don't feel welcome to raise a dissenting opinion as a mere lowly member
> of the Django community.
>

If that’s your perception, then we as a community clearly have a problem
that needs to be addressed.

You’ve been around the Django community since (AFAICT) 2009. You’re a
technical director at a well known and well respected Django consultancy.
You’ve given talks at DjangoCons. You’ve co-written a book about Django for
O’Reilly. If you’re not someone who is in a position to give an informed
opinion on issues with Channels, then I don’t know who is. If you feel like
you’re on the outer and your opinion is not welcome, then that’s *our*
failure, not yours.

I can’t argue with the fact that the DEP process has been circumvented
here. I also acknowledge that this would be doubly frustrating given your
difficulties shepherding the content negotiation DEP. I don’t think I can
give a good answer for why this has been done, other than enthusiasm and
momentum overriding a not-entirely-well-established process.

This thread (and email in general) probably isn’t the best place to flesh
out the solution to these process issues, but they definitely need to be
resolved. Discussion at PyCon and DjangoCon US is definitely called for -
I’ll be at both, and I’d definitely be interested in a BOF or similar
session to field opinions and thoughts from the community about this
process.


> It's pointless for me to continue to elaborate on the things I don't like
> about channels as I'm clearly in the minority and it's going to land. All I
> can do now is beg for these requirements to be optional.
>

Talking about channels specifically: This shouldn’t be true at all. There’s
certainly some momentum, but the code isn’t in trunk, so it’s not too late.
Even if it *was* in trunk - if you could demonstrate that there was a
serious problem, I’d support removing it from the codebase.

I will admin that I haven’t been paying *close* attention to Andrew’s work
- I’m aware of the broad strokes, and I’ve skimmed some of the design
discussions, but I haven’t been keeping close tabs on things. From that
(admittedly weak) position, the only counterargument that I’ve heard are
performance concerns.

However, the last thing I heard on this subject was that the “raw WSGI”
path was essentially unmodified, so there shouldn’t be any particular
performance concerns from adding this to the codebase - just new
functionality for targeting websockets. For me, websockets are a big area
where Django is currently lacking, and everything I’ve read about Andrew’s
proposal has struck me as a reasonable compromise between Django’s need to
respond to a technical requirement, while maintaining ease of
implementation.

I take it that this isn’t your opinion. If you’ve got other concerns - be
they specific implementation issues, or broader philosophical issues, I’d
strongly encourage you to express them. The core team and/or technical
board might not agree with you, but we’d be fools to ignore your experience
and opinions. At the absolute minimum, you’ve earned a considered response
to your concerns.

Yours,
Russ Magee %-)

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

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 6:12 PM, Tim Graham  wrote:

> The future is hard to predict, but I'll add that I'm a tad nervous about
> this as well.
>
> I'm completely inexperienced with channels at this time. Who else has a
> good grasp of the code right now and could help fix release blocking bugs
> if Andrew isn't available? Are we playing for any or all bug fixes? If
> these requests have to go through the MOSS committee, will that delay
> getting things fixed?
>
> Migrations delayed the 1.7 release for months, and I'd like some vote of
> confidence that merging this at such a late stage won't cause similar
> delays.
>
>
I can't speak to everything here, but I do plan to be available through the
course of the release and some time after; that's not ideal from a bus
factor point of view, but it's better than me knowing I'm not around I
guess (unlike migrations, where I was moving continent while it was
landing).

Channels is a simpler patch than migrations IMO, but even labelling it as
"provisional" doesn't get around the fact we need to prevent bugs, it just
saves us in the future if we need to change the API a bit. I have a high
confidence level in it - especially as nearly all of the functionality is
additional, so there's a very low risk of breaking existing Django projects
- but some risk remains.

If you want we could take this to the technical board and get it voted on
(a vote from which I will abstain, since I'm on the same board), which
would seem to be the Right Thing to do given the concerns being raised.

Andrew

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

Re: Django Integration

[Tim Graham]

The future is hard to predict, but I'll add that I'm a tad nervous about 
this as well.

I'm completely inexperienced with channels at this time. Who else has a 
good grasp of the code right now and could help fix release blocking bugs 
if Andrew isn't available? Are we playing for any or all bug fixes? If 
these requests have to go through the MOSS committee, will that delay 
getting things fixed?

Migrations delayed the 1.7 release for months, and I'd like some vote of 
confidence that merging this at such a late stage won't cause similar 
delays.

I'll include the release schedule here as a reminder:

May 16 Django 1.10 alpha; feature freeze. 
June 17 Django 1.10 beta; non-release blocking bug fix freeze. 
July 15 Django 1.10 RC 1; translation string freeze. 
2+ weeks after RC1 
 Django 1.10 final (or RC 2, if needed).
On Wednesday, May 4, 2016 at 8:41:48 PM UTC-4, Mark Lavin wrote:
>
> Major features have never been perfect, no, but they have in the past 
> typically gone through two paths to prove out their design/API/usefulness. 
> One is as an established and mature third-party app such as messages, 
> staticfiles, and django-secure. More recently the other has been through 
> the DEP process: multiple templates (Jinja) and query expressions. Channels 
> has done neither.
>
> Sorry if it seems that I've raised these issues late but I don't feel like 
> there has been a good place for this discussion since the DEP process was 
> circumvented. Most of the development for this has been in Andrew's space. 
> I don't feel welcome to raise a dissenting opinion as a mere lowly member 
> of the Django community. It's pointless for me to continue to elaborate on 
> the things I don't like about channels as I'm clearly in the minority and 
> it's going to land. All I can do now is beg for these requirements to be 
> optional.
>
> - Mark
>
> On Wednesday, May 4, 2016 at 6:48:03 PM UTC-4, Jacob Kaplan-Moss wrote:
>>
>> On Wed, May 4, 2016 at 2:45 PM, Marc Tamlyn  wrote:
>>
>>> Major features merged into Django have generally never been as "perfect" 
>>> as the standards required for smaller patches. There's a recognisation of 
>>> the need for ongoing work, probably over the course of multiple versions, 
>>> in order to perfect any major new feature. The effort involved in getting a 
>>> patch like this to the point it can be merged at all is very significant. 
>>> Many major patches (composite fields, templates widgets...) have previous 
>>> not landed, sometimes multiple times, because they are nowhere near the 
>>> standard that this channels patch is.
>>>
>>> My feeling is that the core team agree with Andrew that this is an 
>>> important direction for Django, and 1.10 is the right release to include it 
>>> in. Bug fixes, additional tests and so on can all be added between alpha 
>>> and final as needed. The important thing is that we have broad agreement 
>>> that the feature is good, the design is right, and an understanding that 
>>> shortcomings will be worked on over the next year or two.
>>>
>>>
>> I agree with this completely. I've been using Channels semi-seriously for 
>> 2-3 months now, and in my opinion it easily clears the bar for inclusion. 
>> The design is right, it's stable in production and under load, and has no 
>> show-stopping bugs I've been able to find. Quite bluntly, it's probably 
>> somewhat better than our average alpha-quality new feature. 
>>
>> My only real concern was around performance regressions, but now that the 
>> WSGI "mode" hits no new code paths, that's no longer a concern. 
>>
>> Jacob 
>>
>>

-- 
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/261d8ffc-3f80-4a05-8e49-0d682aca80e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Mark Lavin]

Major features have never been perfect, no, but they have in the past 
typically gone through two paths to prove out their design/API/usefulness. 
One is as an established and mature third-party app such as messages, 
staticfiles, and django-secure. More recently the other has been through 
the DEP process: multiple templates (Jinja) and query expressions. Channels 
has done neither.

Sorry if it seems that I've raised these issues late but I don't feel like 
there has been a good place for this discussion since the DEP process was 
circumvented. Most of the development for this has been in Andrew's space. 
I don't feel welcome to raise a dissenting opinion as a mere lowly member 
of the Django community. It's pointless for me to continue to elaborate on 
the things I don't like about channels as I'm clearly in the minority and 
it's going to land. All I can do now is beg for these requirements to be 
optional.

- Mark

On Wednesday, May 4, 2016 at 6:48:03 PM UTC-4, Jacob Kaplan-Moss wrote:
>
> On Wed, May 4, 2016 at 2:45 PM, Marc Tamlyn  > wrote:
>
>> Major features merged into Django have generally never been as "perfect" 
>> as the standards required for smaller patches. There's a recognisation of 
>> the need for ongoing work, probably over the course of multiple versions, 
>> in order to perfect any major new feature. The effort involved in getting a 
>> patch like this to the point it can be merged at all is very significant. 
>> Many major patches (composite fields, templates widgets...) have previous 
>> not landed, sometimes multiple times, because they are nowhere near the 
>> standard that this channels patch is.
>>
>> My feeling is that the core team agree with Andrew that this is an 
>> important direction for Django, and 1.10 is the right release to include it 
>> in. Bug fixes, additional tests and so on can all be added between alpha 
>> and final as needed. The important thing is that we have broad agreement 
>> that the feature is good, the design is right, and an understanding that 
>> shortcomings will be worked on over the next year or two.
>>
>>
> I agree with this completely. I've been using Channels semi-seriously for 
> 2-3 months now, and in my opinion it easily clears the bar for inclusion. 
> The design is right, it's stable in production and under load, and has no 
> show-stopping bugs I've been able to find. Quite bluntly, it's probably 
> somewhat better than our average alpha-quality new feature. 
>
> My only real concern was around performance regressions, but now that the 
> WSGI "mode" hits no new code paths, that's no longer a concern. 
>
> Jacob 
>
>

-- 
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/218e4513-91b1-4fad-b18c-b6b0e264fdbc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: re-thinking middleware

[Tim Graham]

I've been working on this and wanted to raise a couple points for 
discussion.

How should we treat error messages in place like system checks where we 
have phrases like "Edit your MIDDLEWARE_CLASSES" ... of course the check 
can easily check both MIDDLEWARE and MIDDLEWARE_CLASSES without much effort 
but should we make the error message "smart" and display the version of the 
setting that the user is using? Alternatively, we could always reference 
MIDDLEWARE (the non-deprecated version) or use some variation like 
"MIDDLEWARE(_CLASSES)" or "MIDDLEWARE/MIDDLEWARE_CLASSES" until the 
deprecation period ends.

Another point for discussion is whether we need to duplicate a lot of tests 
so we test that the middleware continue to work with both the old-style 
MIDDLEWARE_CLASSES and the new style MIDDLEWARE response handling. I guess 
a subclass of anything that uses @override_settings(MIDDLEWARE=...) that 
uses @override_settings(MIDDLEWARE_CLASSES=...) might work. Just putting it 
out there in case anyone has a better idea.

On Monday, January 18, 2016 at 9:20:03 PM UTC-5, Carl Meyer wrote:
>
> I've updated DEP 5 with a new round of clarifications and tweaks based on 
> the most recent feedback: 
> https://github.com/django/deps/compare/62b0...master
>
> 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/9efb8b4b-7010-4f9a-a316-250dffa2a2b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

failure to load fixtures during unit tests

[Rich Rauenzahn]

I'm in the middle of trying to track down a problem with loading fixtures 
during unit tests -- I'm hesitant to call it a bug in Django 1.7, but the 
inconsistent behavior is really stumping me.

Essentially I've made a fixture via

   manage dumpdata --indent=3 -e sessions -e admin -e contenttypes -e 
auth.Permission > test-fixtures.json

If I add that fixtures to my TestCase, it sometimes works if I run each 
test individually (using Django Nose)  -- 

   manage test --failfast test_it:TestClass.test_detail
   manage test --failfast test_it:TestClass.test_list

But if I run them together, 

   manage test --failfast test_it:TestClass

I get errors about duplicate/unique problems.  Essentially a row is 
attempted to be added twice. 

IntegrityError: Problem installing fixture 'test-fixtures.json': Could 
not load app.Branch(pk=1): duplicate key value violates unique constraint 
"app_branch_name_49810fc21046d2e2_uniq"
DETAIL:  Key (name)=(mock) already exists.

(I've also posted this earlier today on django-users, where I also included 
some postgres output).  The tests within the TestCase (or 
TransactionTestCase) can be empty ("pass") and still reproduce.

As best I can tell it doesn't only happen when combined -- sometimes I can 
get it to happen in a class with a single TestCase.  And it isn't always 
the same model that has the conflict.

Has anyone seen anything like this behavior before?  It's as if sometimes 
the fixtures are installed in different order each time, which makes me 
think of some dict.keys() that doesn't return the same order every time.

Rich



-- 
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/37075277-2390-476c-9d32-3b3e594d2e4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Good idea to transition from MS Access to local webapp built on Django?

[Olivier Dalang]

Hi,

We use it here for a similar use case (small NGO's project management
database) and are very happy. It's almost exclusively based on django-admin
to keep everything as modular and easy to maintain as possible, which means
our forms can't be too complex and do reflect the database schema (1 form =
1 database row plus it's 1 to n relations using inlines). We just have a
few specific views to render pdfs using wkhtmltopdf and a a custom
dashboard with shortcuts to the admin change list pages with predefined
filters/ordering.

I'm not very familiar with Access, so I can't easily compare, but the fact
every user can access the same last version through the browser is
definitely a big plus. No need to install, any OS works, users can access
the system from home, etc... By the way, Access and Django are not
necessarily exclusive, as you could perfectly access the database from
Access if you are to produce some specific queries/outputs from Access...

The authentication is very safe as long as you add a throttling on failed
login attempts limit and a session time out, but there are modules for that.

Some say that django-admin isn't meant to be exposed to the users, but only
to the webmaster/developer. I think this only applies to cases where you
don't control who's accessing the site and where you can't teach your users
how the site works.

If you have some more complex workflow needs, have a look at viewflow.io (I
don't use it but it looks interesting).

Any ways, you should just try it, even if you're completely new to python
you'll have something usable really quickly by following the tutorial.

Let us know how it works out !

Olivier



2016-04-29 16:52 GMT+00:00 Patrik Mjartan :

> Hi,
>
> I work for a very small company that I developed an application for, all
> using MS Access (it has back-end MS Access db - although this is planned to
> change to some more robust RDBMS, and a front-end app built in MS Access).
> Currently this app is used to calculate the exact wages of some employees
> (sorry, English is not my native language so I don't know how that type of
> wage is called here, but basically we look at how many products they
> produced and calculate it based on that. It's not a hourly wage). However,
> this summer I would like to expand it to do some order management too (ie.
> each order has specific products that need to be produced... each of those
> can be produced by our employees and so it's directly linked to the wages).
>
> However, it is very hard to manage everything using MS Access. Basically
> each time I make any change to FE or BE, I have to re-distribute the FE to
> all of the front-users. This is not a HUGE problem, the big problem,
> however, is within the MS Access itself, that is, it's very hard to manage
> all the forms as they are listed as simple names (ie. you cannot sub-group
> them efficiently to make a tree-view). Overall I cannot see myself working
> with MS Access in 5 years time as I can already see the scalability
> problems after a few months of working with it.
>
> What I thought of, however, is making a website that is only for local
> use, but is it possible to have the same functionality as a regular
> front-end app? Is this good idea to begin with? I had a brief look at
> Django (I'm VERY new to web-dev, but I'm a fast learner I like to think)
> and I really like it so far. But is it possible to have the same level of
> functionality MS Access offers? That is, for example a sub-form on a form
> that gives more details about the current record selected in the main form?
> Ie. main form consists of overview of 10 recent orders and the lower
> portion of the main form is a subform that displays some detailed info
> about a selected order.
>
> How does it stand from security-perspective if the app is changed from
> local to public? Obviously even on local I'd imagine I'd put a login
> requirement there, similar to how the admin page has it, but how safe is it
> regardless if put to public? Are there pre-determined measures that if
> taken, it will be 100% secure? As you'd imagine I wouldn't be very happy if
> someone deleted all of our inventory records because they could bypass the
> logging system.
>
> Is there any good literature I can read up on doing some similar
> exercises/examples? For instance: orders/inventory management web app?
>
> Thanks a lot in advance!
>
> --
> 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/57c05c25-e8a9-417c-864c-0b21ecb4bcf1%40googlegroups.com

Re: Django Integration

[Jacob Kaplan-Moss]

On Wed, May 4, 2016 at 2:45 PM, Marc Tamlyn  wrote:

> Major features merged into Django have generally never been as "perfect"
> as the standards required for smaller patches. There's a recognisation of
> the need for ongoing work, probably over the course of multiple versions,
> in order to perfect any major new feature. The effort involved in getting a
> patch like this to the point it can be merged at all is very significant.
> Many major patches (composite fields, templates widgets...) have previous
> not landed, sometimes multiple times, because they are nowhere near the
> standard that this channels patch is.
>
> My feeling is that the core team agree with Andrew that this is an
> important direction for Django, and 1.10 is the right release to include it
> in. Bug fixes, additional tests and so on can all be added between alpha
> and final as needed. The important thing is that we have broad agreement
> that the feature is good, the design is right, and an understanding that
> shortcomings will be worked on over the next year or two.
>
>
I agree with this completely. I've been using Channels semi-seriously for
2-3 months now, and in my opinion it easily clears the bar for inclusion.
The design is right, it's stable in production and under load, and has no
show-stopping bugs I've been able to find. Quite bluntly, it's probably
somewhat better than our average alpha-quality new feature.

My only real concern was around performance regressions, but now that the
WSGI "mode" hits no new code paths, that's no longer a concern.

Jacob

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

Re: Django Integration

[Marc Tamlyn]

Major features merged into Django have generally never been as "perfect" as
the standards required for smaller patches. There's a recognisation of the
need for ongoing work, probably over the course of multiple versions, in
order to perfect any major new feature. The effort involved in getting a
patch like this to the point it can be merged at all is very significant.
Many major patches (composite fields, templates widgets...) have previous
not landed, sometimes multiple times, because they are nowhere near the
standard that this channels patch is.

My feeling is that the core team agree with Andrew that this is an
important direction for Django, and 1.10 is the right release to include it
in. Bug fixes, additional tests and so on can all be added between alpha
and final as needed. The important thing is that we have broad agreement
that the feature is good, the design is right, and an understanding that
shortcomings will be worked on over the next year or two.

Marc
On 4 May 2016 8:36 p.m., "Andrew Godwin"  wrote:

>
>
> On Wed, May 4, 2016 at 12:28 PM, Mark Lavin  wrote:
>
>> I can (and do) appreciate the effort that's gone into this work while
>> still feeling as though it isn't ready to be merged with Django. To be
>> honest given that this PR contains almost no changes to Django itself and
>> only adds new code, I don't understand why it can't live outside of Django
>> while it continues to mature.
>>
>>
> That's a perfectly valid question, and one I've debated a lot. It's mostly
> because channels is meant to be a fundamental change to Django (inserting a
> new layer below views and middleware), and having it as something
> officially supported and maintained is far better than having a third-party
> package everyone basically relies on but which doesn't benefit from the
> support of a large team (having been there with South, I know I don't want
> to go back).
>
> It's even more difficult to argue considering it does exist as a perfectly
> functional third-party package for 1.8/1.9, but the goal with channels is,
> for me, to move Django along in the world of web technology and make sure
> it's positioned right for what the job of a webserver is becoming, which as
> far as I am concerned inexorably involves websockets and other "async"
> things, and I think having it in Django itself sends the right message.
>
> Most of the core team I have spoken to about this seem to agree with me,
> which is why I'm pushing so hard. Obviously that trust and maintenance that
> you get by being in core Django comes at a price, and the price is having
> good code in the first place, but I believe that the code is very close to
> being good enough considering we're labelling the whole feature as
> "provisional" in 1.10 anyway (which is something Python recently started
> doing for similar not-experimental but not-100%-final APIs)
>
> (Also, I would posit that the fact it barely changes anything in Django is
> part of the good design, but I am biased there!)
>
> Andrew
>
> --
> 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/CAFwN1uqpLNTLDuZzNQzH_4k_ZYzHx0pbuXzeKo7u80MjVMr3HA%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/CAMwjO1Fx08P2LOPdgDQoav35Vb-gYXiMyrZXhXO3SvjqgzHPCQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Call for Channels work

[Andrew Godwin]

Hi everyone,

We finally have everything in place to pay people from the MOSS funds given
to us by Mozilla for Channels (and more importantly we now have the money
itself), so now I'd like to open the call for help.

We have a list of tasks that need doing in Channels, and the money to pay
people for it, so we would, naturally, like to find people we can pay that
money to. Cruicially, we are *pre-approving* people to work on projects
with a daily (or similar) rate; we don't want people to complete something
and then not get what they expected, have someone do a fixed quote and end
up not being able to finish, or have two people go after the same task.

The list of things that needs doing is here:
https://code.djangoproject.com/wiki/ChannelsTasks

If you'd like to work on one of these things, get in touch with me directly
(and...@aeracode.org) to discuss the task and what's involved; once you're
fully briefed and think you have a handle on the work, our separate Django
MOSS committee will take over approval of the request. (I am not on that
committee for conflict of interest reasons, but am trying to help out where
I can with the process)

Like GSOC, we expect people applying to work on these tasks to have at
least some track record of contributing to open source and working with
Django or a similar project; we are unlikely to approve someone with no
visible experience.

The most pressing issues are all test-related - specifically around
building out a comprehensive test suite around Daphne and the workers, and
getting load testing and similar trials done on the code so it can start to
be honed for full release. If you're at all interested in this work, I
strongly encourage you to get in touch.

If you have any questions, feel free to respond here or email me directly!

Andrew

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

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 12:28 PM, Mark Lavin  wrote:

> I can (and do) appreciate the effort that's gone into this work while
> still feeling as though it isn't ready to be merged with Django. To be
> honest given that this PR contains almost no changes to Django itself and
> only adds new code, I don't understand why it can't live outside of Django
> while it continues to mature.
>
>
That's a perfectly valid question, and one I've debated a lot. It's mostly
because channels is meant to be a fundamental change to Django (inserting a
new layer below views and middleware), and having it as something
officially supported and maintained is far better than having a third-party
package everyone basically relies on but which doesn't benefit from the
support of a large team (having been there with South, I know I don't want
to go back).

It's even more difficult to argue considering it does exist as a perfectly
functional third-party package for 1.8/1.9, but the goal with channels is,
for me, to move Django along in the world of web technology and make sure
it's positioned right for what the job of a webserver is becoming, which as
far as I am concerned inexorably involves websockets and other "async"
things, and I think having it in Django itself sends the right message.

Most of the core team I have spoken to about this seem to agree with me,
which is why I'm pushing so hard. Obviously that trust and maintenance that
you get by being in core Django comes at a price, and the price is having
good code in the first place, but I believe that the code is very close to
being good enough considering we're labelling the whole feature as
"provisional" in 1.10 anyway (which is something Python recently started
doing for similar not-experimental but not-100%-final APIs)

(Also, I would posit that the fact it barely changes anything in Django is
part of the good design, but I am biased there!)

Andrew

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

Re: Django Integration

[Mark Lavin]

I can (and do) appreciate the effort that's gone into this work while still 
feeling as though it isn't ready to be merged with Django. To be honest 
given that this PR contains almost no changes to Django itself and only 
adds new code, I don't understand why it can't live outside of Django while 
it continues to mature.

Best,

Mark

On Wednesday, May 4, 2016 at 3:18:03 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 11:52 AM, Mark Lavin  > wrote:
>
>>
>>
>> Given that there is no guarantee of message delivery, I don't think this 
>> is suitable or recommended for using for background tasks. I don't think 
>> the Django docs should encourage that usage. At least without a strong 
>> warning that this isn't a good idea.
>>  
>>
>>>
 There are tests for the routing and request handling but there are no 
 unittests that I can see for the auth/session handling,

>>>
>>> Yes, these are missing.
>>>  
>>>
 Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes 
 and their usage,

>>>
>>> The ASGI conformance test suite takes care of this: 
>>> https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
>>>  
>>> (that's also used for the inmemory module and asgi_redis in their test 
>>> suites)
>>>
>>  
>>>
>>
>> Yes the code is covered by integration/functional tests but again I feel 
>> like there should be unittests for this as well.
>>
>
> Those are unit tests as far as I'm concerned, and they're quite 
> comprehensive - there's no smaller units of work to really write tests 
> _for_ in any of these backends.
>  
>
>>  
>>
>>> or the worker/runworker code.

>>>
>>> What would you suggest these tests look like? They can't spin up a 
>>> worker and fire requests at it, and most of the worker code is interactive.
>>>
>>
>> It is certainly possible to fire up a worker in a subprocess and test it 
>> that way. Or you could create an instance of the Worker object and call its 
>> methods.
>>
>
> I'll look into this, but firing up subprocesses won't work as it suddenly 
> introduces Redis as a test dependency (right now all tests use the 
> in-memory backend).
>  
>
>>  
>>
>>>  
>>>
 The changes to runserver aren't tested.

>>>
>>> Runserver in Django only has a single test, presumably for the same 
>>> reason; I don't know how I can write a test for this considering the 
>>> autoreload and extra process mechanisms we'd want to cover.
>>>
>>  
>>>
 The new test utilities aren't tested either (yes that's a thing).

>>>
>>> I would say that the usage of those utilities in other tests means they 
>>> are tested sufficiently, given that they're used sufficiently; writing a 
>>> test for just the channel test case would look very similar to the basic 
>>> tests elsewhere.
>>>
>>
>> The existing test utilities (test client, asserting the number of 
>> queries, overriding settings, etc) have tests of their own 
>> https://github.com/django/django/blob/master/tests/test_utils/tests.py 
>> as do the extensions added by contrib.staticfiles. I don't see why Channels 
>> is special and therefore doesn't need them.
>>
>
> I would counter that by saying that the Channels test handler code is only 
> about 20 additional lines of logic and no new assertions, so the existing 
> suite is more than enough.
>  
>
>>  
>>
>>>  
>>>
 All new code should have tests. Isn't that Django's current standard?

>>>
>>> There's no clear standard, the docs just say the tests should "exercise 
>>> all of the new features". I admit that auth/session needs tests - I'll get 
>>> those done this week - but I don't see how we can reasonably test the 
>>> interactive commands in an automated fashion given the current test harness 
>>> (and lack of tests for things like runserver) in Django.
>>>
>>
>> To me it's a bad code smell when code is hard to test. I can't believe 
>> I'm having to convince anyone in this community about the value of testing.
>>
>
> Well, it is hard to test, mostly due to the fact that testing websockets 
> requires the test client to also be asynchronous as well as the server, and 
> if they're in the same process that leads to trouble.
>
> I am very much aware of the value of testing, but I'm saying that in this 
> case it's a large hurdle to climb, I believe the tradeoff is acceptable to 
> merge it in for the alpha as it is and then get the MOSS program to pay 
> some people to work on just this part so it gets the right level of 
> attention.
>  
>
>>  
>>
>>>  
>>>
 appreciate
 asgiref has one "basic" test around WSGI handling which the usage is 
 documented in this change. I don't think anyone would dare say that covers 
 potential edge cases in WSGI/HTTP handling. Not test related, the status 
 code map is also missing many HTTP status codes.

>>>
>>> The WSGI handling part of asgiref is not considered complete, and I will 
>>> probably remove the section 

Re: Django Integration

[Mark Lavin]

I like Markus' suggestion and I think that's in line with how Django 
handles other optional dependencies such as the db bindings 
(psycopg2, MySQLdb, etc). Those raise an ImproperlyConfigured exception 
when there is an import error. The memcache cache backend on the other hand 
raises an import error if python-memcached isn't installed.

On Wednesday, May 4, 2016 at 1:09:40 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 10:06 AM, Markus Holtermann <
> in...@markusholtermann.eu > wrote:
>
>> What about having asgiref and daphne as optional dependencies instead of
>> hard once and raising a proper exception "please install ..." when the
>> import fails?
>>
>> ```
>> try:
>>from asgiref import ...
>> except ImportError:
>>raise ImportError(
>>"Please ensure you installed asgiref to use this feature. Do so "
>> "with `pip install Django[channels]"
>>)
>> ```
>>
>> i.e. `pip install "Django[channels]"` ?
>>
>
> That is the other option, but it seems to run contrary to Django's 
> traditional batteries-included philosophy (and would result in some ugly, 
> ugly import code in the channels modules). I'm curious to hear more 
> opinions though, if there's support for it I'm happy to change it.
>
> Andrew 
>

-- 
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/c696555b-4d08-40e6-b1b5-f3e492b60249%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 11:52 AM, Mark Lavin  wrote:

>
>
> Given that there is no guarantee of message delivery, I don't think this
> is suitable or recommended for using for background tasks. I don't think
> the Django docs should encourage that usage. At least without a strong
> warning that this isn't a good idea.
>
>
>>
>>> There are tests for the routing and request handling but there are no
>>> unittests that I can see for the auth/session handling,
>>>
>>
>> Yes, these are missing.
>>
>>
>>> Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes
>>> and their usage,
>>>
>>
>> The ASGI conformance test suite takes care of this:
>> https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
>> (that's also used for the inmemory module and asgi_redis in their test
>> suites)
>>
>
>>
>
> Yes the code is covered by integration/functional tests but again I feel
> like there should be unittests for this as well.
>

Those are unit tests as far as I'm concerned, and they're quite
comprehensive - there's no smaller units of work to really write tests
_for_ in any of these backends.


>
>
>> or the worker/runworker code.
>>>
>>
>> What would you suggest these tests look like? They can't spin up a worker
>> and fire requests at it, and most of the worker code is interactive.
>>
>
> It is certainly possible to fire up a worker in a subprocess and test it
> that way. Or you could create an instance of the Worker object and call its
> methods.
>

I'll look into this, but firing up subprocesses won't work as it suddenly
introduces Redis as a test dependency (right now all tests use the
in-memory backend).


>
>
>>
>>
>>> The changes to runserver aren't tested.
>>>
>>
>> Runserver in Django only has a single test, presumably for the same
>> reason; I don't know how I can write a test for this considering the
>> autoreload and extra process mechanisms we'd want to cover.
>>
>
>>
>>> The new test utilities aren't tested either (yes that's a thing).
>>>
>>
>> I would say that the usage of those utilities in other tests means they
>> are tested sufficiently, given that they're used sufficiently; writing a
>> test for just the channel test case would look very similar to the basic
>> tests elsewhere.
>>
>
> The existing test utilities (test client, asserting the number of queries,
> overriding settings, etc) have tests of their own
> https://github.com/django/django/blob/master/tests/test_utils/tests.py as
> do the extensions added by contrib.staticfiles. I don't see why Channels is
> special and therefore doesn't need them.
>

I would counter that by saying that the Channels test handler code is only
about 20 additional lines of logic and no new assertions, so the existing
suite is more than enough.


>
>
>>
>>
>>> All new code should have tests. Isn't that Django's current standard?
>>>
>>
>> There's no clear standard, the docs just say the tests should "exercise
>> all of the new features". I admit that auth/session needs tests - I'll get
>> those done this week - but I don't see how we can reasonably test the
>> interactive commands in an automated fashion given the current test harness
>> (and lack of tests for things like runserver) in Django.
>>
>
> To me it's a bad code smell when code is hard to test. I can't believe I'm
> having to convince anyone in this community about the value of testing.
>

Well, it is hard to test, mostly due to the fact that testing websockets
requires the test client to also be asynchronous as well as the server, and
if they're in the same process that leads to trouble.

I am very much aware of the value of testing, but I'm saying that in this
case it's a large hurdle to climb, I believe the tradeoff is acceptable to
merge it in for the alpha as it is and then get the MOSS program to pay
some people to work on just this part so it gets the right level of
attention.


>
>
>>
>>
>>>
>>> asgiref has one "basic" test around WSGI handling which the usage is
>>> documented in this change. I don't think anyone would dare say that covers
>>> potential edge cases in WSGI/HTTP handling. Not test related, the status
>>> code map is also missing many HTTP status codes.
>>>
>>
>> The WSGI handling part of asgiref is not considered complete, and I will
>> probably remove the section about using it in the main Django docs. Only
>> the inmemory backend should be considered used by Django.
>>
>
>>
>
> This is exactly my point. This project is not complete. That is not at all
> clear from this PR or from looking at the asgiref README which only
> re-enforces my feeling that this dependency should not be a requirement
> when installing Django.
>

Of course the project isn't complete, if it was I wouldn't be trying to
merge it in for an alpha; would you feel happier if I upped asgiref to
version 1.0 and stuck a comment on the wsgi part saying it's not done?

Please appreciate that I've spent a hell of a lot of time getting the

Re: Django Integration

[Mark Lavin]

On Wednesday, May 4, 2016 at 12:39:02 PM UTC-4, Andrew Godwin wrote:
>
>
>
> On Wed, May 4, 2016 at 8:26 AM, Mark Lavin  > wrote:
>
>> As noted in the PR there is at least one new setting, 
>> CHANNEL_SESSION_ENGINE, which is lacking documentation.
>>
>
> That's been added now.
>  
>
>> The notes on deployment for "Running ASGI under WSGI" don't give any 
>> motivation why you would want to do this given that it doesn't support 
>> websockets in this case. Is there any advantages? Disadvantages?
>>
>
> It lets you still have background tasks and non-WebSocket interface 
> servers (or run websocket interfaces separately). I've expanded the docs to 
> say this.
>
 
>

Given that there is no guarantee of message delivery, I don't think this is 
suitable or recommended for using for background tasks. I don't think the 
Django docs should encourage that usage. At least without a strong warning 
that this isn't a good idea.
 

>
>> There are tests for the routing and request handling but there are no 
>> unittests that I can see for the auth/session handling,
>>
>
> Yes, these are missing.
>  
>
>> Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes and 
>> their usage,
>>
>
> The ASGI conformance test suite takes care of this: 
> https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
>  
> (that's also used for the inmemory module and asgi_redis in their test 
> suites)
>
 
>

Yes the code is covered by integration/functional tests but again I feel 
like there should be unittests for this as well.
 

> or the worker/runworker code.
>>
>
> What would you suggest these tests look like? They can't spin up a worker 
> and fire requests at it, and most of the worker code is interactive.
>

It is certainly possible to fire up a worker in a subprocess and test it 
that way. Or you could create an instance of the Worker object and call its 
methods.
 

>  
>
>> The changes to runserver aren't tested.
>>
>
> Runserver in Django only has a single test, presumably for the same 
> reason; I don't know how I can write a test for this considering the 
> autoreload and extra process mechanisms we'd want to cover.
>
 
>
>> The new test utilities aren't tested either (yes that's a thing).
>>
>
> I would say that the usage of those utilities in other tests means they 
> are tested sufficiently, given that they're used sufficiently; writing a 
> test for just the channel test case would look very similar to the basic 
> tests elsewhere.
>

The existing test utilities (test client, asserting the number of queries, 
overriding settings, etc) have tests of their own 
https://github.com/django/django/blob/master/tests/test_utils/tests.py as 
do the extensions added by contrib.staticfiles. I don't see why Channels is 
special and therefore doesn't need them.
 

>  
>
>> All new code should have tests. Isn't that Django's current standard?
>>
>
> There's no clear standard, the docs just say the tests should "exercise 
> all of the new features". I admit that auth/session needs tests - I'll get 
> those done this week - but I don't see how we can reasonably test the 
> interactive commands in an automated fashion given the current test harness 
> (and lack of tests for things like runserver) in Django.
>

To me it's a bad code smell when code is hard to test. I can't believe I'm 
having to convince anyone in this community about the value of testing.
 

>  
>
>>
>> asgiref has one "basic" test around WSGI handling which the usage is 
>> documented in this change. I don't think anyone would dare say that covers 
>> potential edge cases in WSGI/HTTP handling. Not test related, the status 
>> code map is also missing many HTTP status codes.
>>
>
> The WSGI handling part of asgiref is not considered complete, and I will 
> probably remove the section about using it in the main Django docs. Only 
> the inmemory backend should be considered used by Django.
>
 
>

This is exactly my point. This project is not complete. That is not at all 
clear from this PR or from looking at the asgiref README which only 
re-enforces my feeling that this dependency should not be a requirement 
when installing Django.
 

>
>> I'm not in favor of on leeway for external dependencies for the reason 
>> you note: they are in the install_requires. Django has avoided having 
>> required dependencies and I don't think it sets a good precedent to have 
>> the first set be those which don't meet the quality standards expected by 
>> the community. That is they don't have sufficient docs/tests to be include 
>> in Django itself. It isn't clear why these are required if you are claiming 
>> that they aren't required to run. If these we're in the install_requires 
>> then I would withdraw the objections about them with regard to this change 
>> in Django.
>>
>
> With a change I'm going to make, Django will depend on these in 
> install_requires but not actually use them until you try 

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 10:06 AM, Markus Holtermann  wrote:

> What about having asgiref and daphne as optional dependencies instead of
> hard once and raising a proper exception "please install ..." when the
> import fails?
>
> ```
> try:
>from asgiref import ...
> except ImportError:
>raise ImportError(
>"Please ensure you installed asgiref to use this feature. Do so "
> "with `pip install Django[channels]"
>)
> ```
>
> i.e. `pip install "Django[channels]"` ?
>

That is the other option, but it seems to run contrary to Django's
traditional batteries-included philosophy (and would result in some ugly,
ugly import code in the channels modules). I'm curious to hear more
opinions though, if there's support for it I'm happy to change it.

Andrew

-- 
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/CAFwN1ursVi2g%2BFCj1vY5w%3Df6LOtYyxZackEFhinVF3oBD%2BCPvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Markus Holtermann]

What about having asgiref and daphne as optional dependencies instead of
hard once and raising a proper exception "please install ..." when the
import fails?

```
try:
   from asgiref import ...
except ImportError:
   raise ImportError(
   "Please ensure you installed asgiref to use this feature. Do so "
"with `pip install Django[channels]"
   )
```

i.e. `pip install "Django[channels]"` ?

/Markus

On Wed, May 04, 2016 at 09:38:33AM -0700, Andrew Godwin wrote:

On Wed, May 4, 2016 at 8:26 AM, Mark Lavin  wrote:


As noted in the PR there is at least one new setting,
CHANNEL_SESSION_ENGINE, which is lacking documentation.



That's been added now.



The notes on deployment for "Running ASGI under WSGI" don't give any
motivation why you would want to do this given that it doesn't support
websockets in this case. Is there any advantages? Disadvantages?



It lets you still have background tasks and non-WebSocket interface servers
(or run websocket interfaces separately). I've expanded the docs to say
this.




There are tests for the routing and request handling but there are no
unittests that I can see for the auth/session handling,



Yes, these are missing.



Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes and
their usage,



The ASGI conformance test suite takes care of this:
https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
(that's also used for the inmemory module and asgi_redis in their test
suites)



or the worker/runworker code.



What would you suggest these tests look like? They can't spin up a worker
and fire requests at it, and most of the worker code is interactive.



The changes to runserver aren't tested.



Runserver in Django only has a single test, presumably for the same reason;
I don't know how I can write a test for this considering the autoreload and
extra process mechanisms we'd want to cover.



The new test utilities aren't tested either (yes that's a thing).



I would say that the usage of those utilities in other tests means they are
tested sufficiently, given that they're used sufficiently; writing a test
for just the channel test case would look very similar to the basic tests
elsewhere.



All new code should have tests. Isn't that Django's current standard?



There's no clear standard, the docs just say the tests should "exercise all
of the new features". I admit that auth/session needs tests - I'll get
those done this week - but I don't see how we can reasonably test the
interactive commands in an automated fashion given the current test harness
(and lack of tests for things like runserver) in Django.




asgiref has one "basic" test around WSGI handling which the usage is
documented in this change. I don't think anyone would dare say that covers
potential edge cases in WSGI/HTTP handling. Not test related, the status
code map is also missing many HTTP status codes.



The WSGI handling part of asgiref is not considered complete, and I will
probably remove the section about using it in the main Django docs. Only
the inmemory backend should be considered used by Django.




I'm not in favor of on leeway for external dependencies for the reason you
note: they are in the install_requires. Django has avoided having required
dependencies and I don't think it sets a good precedent to have the first
set be those which don't meet the quality standards expected by the
community. That is they don't have sufficient docs/tests to be include in
Django itself. It isn't clear why these are required if you are claiming
that they aren't required to run. If these we're in the install_requires
then I would withdraw the objections about them with regard to this change
in Django.



With a change I'm going to make, Django will depend on these in
install_requires but not actually use them until you try and use a channels
feature; they're in install_requires out of user convenience (having a
traceback the first time you use the new built-in Django feature seems
bad). Considering we're launching Channels in 1.10 as a "provisional"
feature, my opinion would be that we can go slightly easier on these
dependencies (but of course I'm biased)

Andrew




On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote:



On Wed, May 4, 2016 at 6:15 AM, Mark Lavin  wrote:


I had assumed this was still a work in progress because there are
missing tests and some documentation. The build is passing but the unittest
coverage for the new modules seems low or at least not up to the standards
I expect for Django contributions. The same for the daphne and asgiref
packages which are new requirements. In previous discussions there were
talks about performance benchmarks to track potential regressions before
this would be accepted similar to the template-based widget rendering
change. I don't see any references here or in this work. What is the status
of those?



- The 

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 8:26 AM, Mark Lavin  wrote:

> As noted in the PR there is at least one new setting,
> CHANNEL_SESSION_ENGINE, which is lacking documentation.
>

That's been added now.


> The notes on deployment for "Running ASGI under WSGI" don't give any
> motivation why you would want to do this given that it doesn't support
> websockets in this case. Is there any advantages? Disadvantages?
>

It lets you still have background tasks and non-WebSocket interface servers
(or run websocket interfaces separately). I've expanded the docs to say
this.


>
> There are tests for the routing and request handling but there are no
> unittests that I can see for the auth/session handling,
>

Yes, these are missing.


> Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes and
> their usage,
>

The ASGI conformance test suite takes care of this:
https://github.com/andrewgodwin/django/blob/channels/tests/channels_tests/test_database_layer.py#L3
(that's also used for the inmemory module and asgi_redis in their test
suites)


> or the worker/runworker code.
>

What would you suggest these tests look like? They can't spin up a worker
and fire requests at it, and most of the worker code is interactive.


> The changes to runserver aren't tested.
>

Runserver in Django only has a single test, presumably for the same reason;
I don't know how I can write a test for this considering the autoreload and
extra process mechanisms we'd want to cover.


> The new test utilities aren't tested either (yes that's a thing).
>

I would say that the usage of those utilities in other tests means they are
tested sufficiently, given that they're used sufficiently; writing a test
for just the channel test case would look very similar to the basic tests
elsewhere.


> All new code should have tests. Isn't that Django's current standard?
>

There's no clear standard, the docs just say the tests should "exercise all
of the new features". I admit that auth/session needs tests - I'll get
those done this week - but I don't see how we can reasonably test the
interactive commands in an automated fashion given the current test harness
(and lack of tests for things like runserver) in Django.


>
> asgiref has one "basic" test around WSGI handling which the usage is
> documented in this change. I don't think anyone would dare say that covers
> potential edge cases in WSGI/HTTP handling. Not test related, the status
> code map is also missing many HTTP status codes.
>

The WSGI handling part of asgiref is not considered complete, and I will
probably remove the section about using it in the main Django docs. Only
the inmemory backend should be considered used by Django.


>
> I'm not in favor of on leeway for external dependencies for the reason you
> note: they are in the install_requires. Django has avoided having required
> dependencies and I don't think it sets a good precedent to have the first
> set be those which don't meet the quality standards expected by the
> community. That is they don't have sufficient docs/tests to be include in
> Django itself. It isn't clear why these are required if you are claiming
> that they aren't required to run. If these we're in the install_requires
> then I would withdraw the objections about them with regard to this change
> in Django.
>

With a change I'm going to make, Django will depend on these in
install_requires but not actually use them until you try and use a channels
feature; they're in install_requires out of user convenience (having a
traceback the first time you use the new built-in Django feature seems
bad). Considering we're launching Channels in 1.10 as a "provisional"
feature, my opinion would be that we can go slightly easier on these
dependencies (but of course I'm biased)

Andrew


>
> On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote:
>
>>
>> On Wed, May 4, 2016 at 6:15 AM, Mark Lavin  wrote:
>>
>>> I had assumed this was still a work in progress because there are
>>> missing tests and some documentation. The build is passing but the unittest
>>> coverage for the new modules seems low or at least not up to the standards
>>> I expect for Django contributions. The same for the daphne and asgiref
>>> packages which are new requirements. In previous discussions there were
>>> talks about performance benchmarks to track potential regressions before
>>> this would be accepted similar to the template-based widget rendering
>>> change. I don't see any references here or in this work. What is the status
>>> of those?
>>>
>>>
>> - The documentation on Channels is considerably more than I would have
>> accepted for a patch. What do you think is missing?
>>
>> - The channels branch is likely missing some tests around auth and
>> session in particular, but a lot of the "main" stuff has tests; what would
>> you need before accepting it?
>>
>> - asgiref quite literally has more tests than actual code we're using, so
>> I 

Re: Django Integration

[Mark Lavin]

As noted in the PR there is at least one new setting, 
CHANNEL_SESSION_ENGINE, which is lacking documentation. The notes on 
deployment for "Running ASGI under WSGI" don't give any motivation why you 
would want to do this given that it doesn't support websockets in this 
case. Is there any advantages? Disadvantages?

There are tests for the routing and request handling but there are no 
unittests that I can see for the auth/session handling, 
Channel/Message/Group/ChannelLayerManager/custom JSON encoder classes and 
their usage, or the worker/runworker code. The changes to runserver aren't 
tested. The new test utilities aren't tested either (yes that's a thing). 
All new code should have tests. Isn't that Django's current standard?

asgiref has one "basic" test around WSGI handling which the usage is 
documented in this change. I don't think anyone would dare say that covers 
potential edge cases in WSGI/HTTP handling. Not test related, the status 
code map is also missing many HTTP status codes.

I'm not in favor of on leeway for external dependencies for the reason you 
note: they are in the install_requires. Django has avoided having required 
dependencies and I don't think it sets a good precedent to have the first 
set be those which don't meet the quality standards expected by the 
community. That is they don't have sufficient docs/tests to be include in 
Django itself. It isn't clear why these are required if you are claiming 
that they aren't required to run. If these we're in the install_requires 
then I would withdraw the objections about them with regard to this change 
in Django.

-Mark

On Wednesday, May 4, 2016 at 10:26:22 AM UTC-4, Andrew Godwin wrote:

>
> On Wed, May 4, 2016 at 6:15 AM, Mark Lavin  > wrote:
>
>> I had assumed this was still a work in progress because there are missing 
>> tests and some documentation. The build is passing but the unittest 
>> coverage for the new modules seems low or at least not up to the standards 
>> I expect for Django contributions. The same for the daphne and asgiref 
>> packages which are new requirements. In previous discussions there were 
>> talks about performance benchmarks to track potential regressions before 
>> this would be accepted similar to the template-based widget rendering 
>> change. I don't see any references here or in this work. What is the status 
>> of those?
>>
>>
> - The documentation on Channels is considerably more than I would have 
> accepted for a patch. What do you think is missing?
>
> - The channels branch is likely missing some tests around auth and session 
> in particular, but a lot of the "main" stuff has tests; what would you need 
> before accepting it?
>
> - asgiref quite literally has more tests than actual code we're using, so 
> I don't see a problem there
>
> - Daphne is severely lacking in tests for WebSocket encoding/decoding 
> support as writing a test harness for it is ridiculously hard and I was 
> hoping to get some help on that now we finally have the MOSS money around.
>
> - There are no performance regression tests as by default the codepath in 
> Django is the same as before (apart from runserver, which in my basic tests 
> actually sped up); as long as you deploy using WSGI, you never even touch 
> Channels code (which wasn't the original plan, but now is for sanity 
> reasons).
>
> I would like some leeway on the external dependencies being fully tested 
> considering that they are not beholden to Django's release cycle, but maybe 
> because we're declaring them as core dependencies (I patched in 
> install_requires into setup.py for them) we should be very strict? If this 
> patch is going to be denied based on Daphne not having sufficient test 
> coverage then I suspect we'll miss the deadline and have to foist this on 
> the LTS instead, which I really don't want.
>
> Andrew
>

-- 
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/0b519047-96ee-4ac9-9230-0f487625a7e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: upgrade from 1.4 to 1.8

[Tim Graham]

I don't recall any similar reports. Anyway, "is it a bug?" questions go to 
django-users. You'll need to include steps to reproduce the issue in order 
to get help.

On Wednesday, May 4, 2016 at 7:29:52 AM UTC-4, Samarjeet Singh wrote:
>
> the problem is on the flush function of django 1.8 and because of which 
> the session is deleted instead of modifying and then a new session is 
> created at logout and which gets conflicted with the new user session so 
> that is why i am not able to log in .so is this problem with me only or 
> others also
>
>
> On Tuesday, May 3, 2016 at 6:19:57 PM UTC+5:30, Florian Apolloner wrote:
>>
>> Hi,
>>
>> this mailing list is about the development of Django itself. Please 
>> direct usage questions to the django-users mailing list.
>>
>> Cheers,
>> Florian
>>
>> On Tuesday, May 3, 2016 at 12:06:44 PM UTC+2, Samarjeet Singh wrote:
>>>
>>> The problem i am facing is :
>>> 1.login to the app every thing is fine
>>> 2.logout
>>> 3.login back again (then if i click on any tab it redirects me to the 
>>> login page back again )
>>>
>>> any idea what can be the problem ???
>>> PS:one more thing previously when the user does a login the number of 
>>> key was same in the session table(the session key was modified) but now in 
>>> 1.8 the number of session key entry increases by two or more. 
>>>
>>

-- 
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/06d2b2d1-e1f8-4ef7-b806-0ec1f74db6f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Andrew Godwin]

On Wed, May 4, 2016 at 6:15 AM, Mark Lavin  wrote:

> I had assumed this was still a work in progress because there are missing
> tests and some documentation. The build is passing but the unittest
> coverage for the new modules seems low or at least not up to the standards
> I expect for Django contributions. The same for the daphne and asgiref
> packages which are new requirements. In previous discussions there were
> talks about performance benchmarks to track potential regressions before
> this would be accepted similar to the template-based widget rendering
> change. I don't see any references here or in this work. What is the status
> of those?
>
>
- The documentation on Channels is considerably more than I would have
accepted for a patch. What do you think is missing?

- The channels branch is likely missing some tests around auth and session
in particular, but a lot of the "main" stuff has tests; what would you need
before accepting it?

- asgiref quite literally has more tests than actual code we're using, so I
don't see a problem there

- Daphne is severely lacking in tests for WebSocket encoding/decoding
support as writing a test harness for it is ridiculously hard and I was
hoping to get some help on that now we finally have the MOSS money around.

- There are no performance regression tests as by default the codepath in
Django is the same as before (apart from runserver, which in my basic tests
actually sped up); as long as you deploy using WSGI, you never even touch
Channels code (which wasn't the original plan, but now is for sanity
reasons).

I would like some leeway on the external dependencies being fully tested
considering that they are not beholden to Django's release cycle, but maybe
because we're declaring them as core dependencies (I patched in
install_requires into setup.py for them) we should be very strict? If this
patch is going to be denied based on Daphne not having sufficient test
coverage then I suspect we'll miss the deadline and have to foist this on
the LTS instead, which I really don't want.

Andrew

-- 
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/CAFwN1uqfj7720_qHbO2sggF076w4dCOzaRD%2B7qA%3DwrNG%2BcLhFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Integration

[Mark Lavin]

I had assumed this was still a work in progress because there are missing 
tests and some documentation. The build is passing but the unittest 
coverage for the new modules seems low or at least not up to the standards 
I expect for Django contributions. The same for the daphne and asgiref 
packages which are new requirements. In previous discussions there were 
talks about performance benchmarks to track potential regressions before 
this would be accepted similar to the template-based widget rendering 
change. I don't see any references here or in this work. What is the status 
of those?

Best,

Mark

On Tuesday, May 3, 2016 at 9:04:19 PM UTC-4, Andrew Godwin wrote:
>
> I'm basically slowly fixing the test system failures (mostly because I 
> introduced some new packages); the patch is ready to go code-wise, just 
> need to get it green. Let me fix the current set now and see if that pushes 
> it over the edge.
>
> (There are some refinements the patch needs in terms of things like making 
> the enforce_ordering decorator a bit more efficient, but I see these as 
> being entirely valid things to do after the feature freeze)
>
> Andrew
>
> On Tue, May 3, 2016 at 5:57 PM, Tim Graham  > wrote:
>
>> Hi Andrew,
>>
>> How are things going with the patch [0]? Do you think you might have it 
>> ready by next Monday or so, so that I'll have at least a few days to review 
>> it before the alpha scheduled for May 16?
>>
>> [0] https://github.com/django/django/pull/6419
>>
>> On Saturday, March 5, 2016 at 7:49:41 PM UTC-5, Andrew Godwin wrote:
>>>
>>> My intention is still to get it in - the external library is pretty much 
>>> at the stable point now, and I'm preparing to brand it 1.0. Once I do that, 
>>> I'll start work on the Django patch.
>>>
>>> It's made a bit easier by the fact that the code is four repositories, 
>>> three of which (asgiref, daphne, and asgi_redis) can continue to be 
>>> separate modules. Only the code in the "channels" repository needs to go 
>>> into Django itself, and while it's the biggest repo, most of it should slot 
>>> right in; there's not really much in core itself that needs changing, more 
>>> about addition and tweaking some imports.
>>>
>>> Andrew
>>>
>>> On Sat, Mar 5, 2016 at 4:44 PM, Tim Graham  wrote:
>>>
 Hi Andrew,

 What's your thinking about whether or not any of this will make it into 
 1.10? The alpha is scheduled for May 16.

 On Saturday, March 5, 2016 at 2:40:05 PM UTC-5, Andrew Godwin wrote:
>
> Hi Chad,
>
> The REST framework request feature integration, in particular, has not 
> started yet; Mozilla has been having some issues working out how to pay 
> their various grantees, and from my understanding we still haven't 
> received 
> the grant money yet.
>
> Channels is well underway, but that's only because I'm able to do the 
> work now and wait to get paid for it later; I don't expect the same of 
> other contributors.
>
> Andrew
>
> On Fri, Mar 4, 2016 at 3:58 PM, Chad Paulson  
> wrote:
>
>> I was happy to read that part of the Mozilla Open Source Support 
>> program funding that was recently awarded to the Django Software 
>> Foundation 
>> will go toward integrating key components of Django REST Framework into 
>> Django.
>>
>> Since I haven't found any update since the initial announcement in 
>> December, I was curious what the status of this integration is and, if 
>> possible, how soon it might be available.
>>
>>
>> https://www.djangoproject.com/weblog/2015/dec/11/django-awarded-moss-grant/
>>
>> -- 
>> 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/2bdf074c-5e21-48cf-a93c-ba19f7744a89%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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at 

Re: Post-Mortem of the djangoproject.com outage earlier today.

[Jacob Kaplan-Moss]

Thanks for the info, and for the quick fix!

Jacob

On Wed, May 4, 2016 at 3:48 AM, Florian Apolloner 
wrote:

> Hi,
>
> earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from
> our ansible repository to dp.com. This branch included our old (now
> expired) gandi SSL certificate. Once I realized what I did (which took a
> few minutes since I was preparing to push a commit) I switched to the
> proper branch and redeployed (+ notified ops and IRC). This redeployment
> caused our new and shiny letsencrypt.org key to be redeployed (which we
> have been running successfully the last few weeks) but left the old gandi
> crt (the cert not the key!) in place, since letsencrypt automatically
> generates that. At this point nginx would no longer start:
>
> SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/djangoproject.com.key") failed
> (SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key
> values mismatch)
>
> This is kind of an obvious error, as the private key and the cert no
> longer match, which I verified with "openssl x509 -in djangoproject.com.crt
> -text -noout". The solution to this problem is simple, regenerate the cert
> and be done with it -- sadly not that simple since nginx refused to start
> :D Setting ssl to off in nginx.conf had no effect, apparently nginx is
> really picky about unusable ssl certs. Knowing that we configure nginx only
> via ansible I quickly reduced the config to the default server without ssl,
> started it and regenerated the cert. An ansible run restored the original
> config and allowed the server to start again -- executed twice just to
> ensure that the second run would not yield any changes in files (finally at
> 9:56 UTC).
>
> Going forward I think we will do the following:
>  * Monitor SSL certs more closely, it shouldn't take me minutes to notice
> that the cert is broken
>  * See if we can ensure that we push from the correct ansible branch
>  * Find a config that allows nginx to start with invalid certs if possible
> (at least the http listeners), so we can easily reissue certs.
>
> Sorry for the outage,
> Florian
>
> P.S.: On a non-related note: Google should display search results in the
> correct language now :D
>
> --
> 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/992b6ec7-fa82-4392-ba4b-d0f74f09b865%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/CAK8PqJEVqPpEXXzOAaGJEaRYbua%2BJQ4YTrjKk%3DWtoGb7QJUxRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: upgrade from 1.4 to 1.8

[Samarjeet Singh]

i think this is a development issue because of request.session.flush if i 
logout all the session detail is deleted and not modified because of which 
next time when we login there is a session conflict so i dont know if it 
ths problem is with everyone or only  i am facing it .
Please help!!

On Tuesday, May 3, 2016 at 3:36:44 PM UTC+5:30, Samarjeet Singh wrote:
>
> The problem i am facing is :
> 1.login to the app every thing is fine
> 2.logout
> 3.login back again (then if i click on any tab it redirects me to the 
> login page back again )
>
> any idea what can be the problem ???
> PS:one more thing previously when the user does a login the number of key 
> was same in the session table(the session key was modified) but now in 1.8 
> the number of session key entry increases by two or more. 
>

-- 
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/a83eb091-1f8c-4be2-a6b7-3f58d99e189d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: upgrade from 1.4 to 1.8

[Samarjeet Singh]

the problem is on the flush function of django 1.8 and because of which the 
session is deleted instead of modifying and then a new session is created 
at logout and which gets conflicted with the new user session so that is 
why i am not able to log in .so is this problem with me only or others also


On Tuesday, May 3, 2016 at 6:19:57 PM UTC+5:30, Florian Apolloner wrote:
>
> Hi,
>
> this mailing list is about the development of Django itself. Please direct 
> usage questions to the django-users mailing list.
>
> Cheers,
> Florian
>
> On Tuesday, May 3, 2016 at 12:06:44 PM UTC+2, Samarjeet Singh wrote:
>>
>> The problem i am facing is :
>> 1.login to the app every thing is fine
>> 2.logout
>> 3.login back again (then if i click on any tab it redirects me to the 
>> login page back again )
>>
>> any idea what can be the problem ???
>> PS:one more thing previously when the user does a login the number of key 
>> was same in the session table(the session key was modified) but now in 1.8 
>> the number of session key entry increases by two or more. 
>>
>

-- 
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/7f37a97d-d9d9-49ca-a51f-6a84f34fc556%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django website ssl-certificate expired

[Markus Holtermann]

A post-mortem is at 
https://groups.google.com/forum/#!topic/django-developers/7qzh2n3ZDRc

Cheers,

/Markus

On Wednesday, May 4, 2016 at 11:51:08 AM UTC+2, Marc Tamlyn wrote:
>
> We are aware of the issue and are working on it.
>
> Thanks,
> Marc
>
> On 4 May 2016 at 10:30, Wim Feijen  
> wrote:
>
>> Hi guys,
>>
>> Apologies if I am posting in the wrong group, but the certificate of 
>> djangoproject.com expired today (4 May).
>>
>> Wim
>>
>> -- 
>> 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/e44c883b-41fc-4afb-8717-15c0f0f5dae2%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/09961b5c-429b-4949-8287-50c1e4b68ec3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Post-Mortem of the djangoproject.com outage earlier today.

[Florian Apolloner]

Hi,

earlier today (roughly 9:30 UTC) I deployed a wrong (local) branch from our 
ansible repository to dp.com. This branch included our old (now expired) 
gandi SSL certificate. Once I realized what I did (which took a few minutes 
since I was preparing to push a commit) I switched to the proper branch and 
redeployed (+ notified ops and IRC). This redeployment caused our new and 
shiny letsencrypt.org key to be redeployed (which we have been running 
successfully the last few weeks) but left the old gandi crt (the cert not 
the key!) in place, since letsencrypt automatically generates that. At this 
point nginx would no longer start:

SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/djangoproject.com.key") failed 
(SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key 
values mismatch)

This is kind of an obvious error, as the private key and the cert no longer 
match, which I verified with "openssl x509 -in djangoproject.com.crt -text 
-noout". The solution to this problem is simple, regenerate the cert and be 
done with it -- sadly not that simple since nginx refused to start :D 
Setting ssl to off in nginx.conf had no effect, apparently nginx is really 
picky about unusable ssl certs. Knowing that we configure nginx only via 
ansible I quickly reduced the config to the default server without ssl, 
started it and regenerated the cert. An ansible run restored the original 
config and allowed the server to start again -- executed twice just to 
ensure that the second run would not yield any changes in files (finally at 
9:56 UTC).

Going forward I think we will do the following:
 * Monitor SSL certs more closely, it shouldn't take me minutes to notice 
that the cert is broken
 * See if we can ensure that we push from the correct ansible branch
 * Find a config that allows nginx to start with invalid certs if possible 
(at least the http listeners), so we can easily reissue certs.

Sorry for the outage,
Florian

P.S.: On a non-related note: Google should display search results in the 
correct language now :D

-- 
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/992b6ec7-fa82-4392-ba4b-d0f74f09b865%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django website ssl-certificate expired

[Marc Tamlyn]

We are aware of the issue and are working on it.

Thanks,
Marc

On 4 May 2016 at 10:30, Wim Feijen  wrote:

> Hi guys,
>
> Apologies if I am posting in the wrong group, but the certificate of
> djangoproject.com expired today (4 May).
>
> Wim
>
> --
> 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/e44c883b-41fc-4afb-8717-15c0f0f5dae2%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/CAMwjO1HEWHDO7-6P5xv%2BQJUrW7Cc%2BWU0a0KC76iJuax%3DU8srMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django website ssl-certificate expired

[Wim Feijen]

Hi guys,

Apologies if I am posting in the wrong group, but the certificate of 
djangoproject.com expired today (4 May).

Wim

-- 
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/e44c883b-41fc-4afb-8717-15c0f0f5dae2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.