Re: Deprecate FCGI support in Django 1.7

[Curtis Maloney]

Well, mostly to indicate it's primary focus is on providing a FastCGI
server for Django.

I'm quite happy to keep it app agnostic, and be a general FastCGI->WSGI
publisher...


On 24 July 2013 15:04, Joe Tennies  wrote:

> Is there a specific reason to call this "django-fastcgi"? I think it
> should most likely be a generic wsgi to fastcgi binding, right? Or is this
> project mainly the django management commands?
> On Jul 22, 2013 8:07 PM, "Curtis Maloney" 
> wrote:
>
>> Well, having started looking over the flup source, I can see a lot of
>> useful code to crib, as well as a few critical path bits that can be
>> optimised [without even reducing readability!]
>>
>> So, if you feel like helping out with django-fastcgi ... I'm happy for
>> the help :)
>>
>> --
>> Curtis
>>
>>
>>
>> On 23 July 2013 03:25, Some Developer  wrote:
>>
>>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>>
 The hope is to start accelerating the release cycle slightly; however,
 this also depends on someone actually doing the work :-)

>>>
>>> Sounds good. I'd love to start helping with Django myself but I feel a
>>> bit lost when it comes to useful things to do. Maybe I'll start checking
>>> out the bug tracker and seeing what I can do there.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to 
>>> django-developers+unsubscribe@**googlegroups.com
>>> .
>>> To post to this group, send email to django-developers@**
>>> googlegroups.com .
>>> Visit this group at 
>>> http://groups.google.com/**group/django-developers
>>> .
>>> For more options, visit 
>>> https://groups.google.com/**groups/opt_out
>>> .
>>>
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Joe Tennies]

Is there a specific reason to call this "django-fastcgi"? I think it should
most likely be a generic wsgi to fastcgi binding, right? Or is this project
mainly the django management commands?
On Jul 22, 2013 8:07 PM, "Curtis Maloney" 
wrote:

> Well, having started looking over the flup source, I can see a lot of
> useful code to crib, as well as a few critical path bits that can be
> optimised [without even reducing readability!]
>
> So, if you feel like helping out with django-fastcgi ... I'm happy for the
> help :)
>
> --
> Curtis
>
>
>
> On 23 July 2013 03:25, Some Developer  wrote:
>
>> On 22/07/13 10:00, Russell Keith-Magee wrote:
>>
>>> The hope is to start accelerating the release cycle slightly; however,
>>> this also depends on someone actually doing the work :-)
>>>
>>
>> Sounds good. I'd love to start helping with Django myself but I feel a
>> bit lost when it comes to useful things to do. Maybe I'll start checking
>> out the bug tracker and seeing what I can do there.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to 
>> django-developers+unsubscribe@**googlegroups.com
>> .
>> To post to this group, send email to 
>> django-developers@**googlegroups.com
>> .
>> Visit this group at 
>> http://groups.google.com/**group/django-developers
>> .
>> For more options, visit 
>> https://groups.google.com/**groups/opt_out
>> .
>>
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Russell Keith-Magee]

On Wed, Jul 24, 2013 at 4:17 AM, Christopher Medrela <
chris.medr...@gmail.com> wrote:

> Progress: I've implemented registering entry points. Now there is
> `django.core.checks.register(callable)` function. There is no
> `run_in_development` and `run_in_production` arguments. I've also rewritten
> mechanism of triggering checking framework -- `BaseCommand.validate` calls
> `django.core.checks.run_checks` instead of `get_validation_errors` (which
> was
> deleted) now.
>
> Questions:
>
> 1. BaseCommand.validate have an `app` optional argument to run validation
> of a
> particular app (if app==None then all checks are performed).
> Unfortunately, with
> the current checking framework, we are not able to run checks for a
> particular
> app. The attribute isn't used anywhere in Django except for three tests
> [1] and
> I don't think that this is heavily used by third party commands. So I
> propose to
> deprecate this attribute if it's possible.
>
> [1]
> https://github.com/django/django/blob/master/django/contrib/auth/tests/test_management.py#L176
>

What's the technical cause of needing to drop this feature? Is it because
checks are no longer guaranteed to be "app specific"? Or is there some
other cause?

At the end of the day, I don't especially mind if we have to drop this as a
feature for the new checks framework. Checks really are something that
should be run in their entirety, and if you get any errors, then . However,
I can see how some people might have use for running a subset of checks
against a subset of the project. If we need to drop this feature, I want to
make sure we're not dropping it for a good reason, not just because it
would be harder to implement.


> 2a. Warnings are printed with bold, yellow foreground now (errors use red
> color). Is it a good choice?
>

Sounds good to me.


> 2b. The rules of formatting error messages are that the error message
> (that may
> be multiline) is followed by the hint in the next line, i. e.:
>
> app_label.model_label: Error message.
> Error message can be multilined. In that case, the first line should
> be a short description and the rest should be a long description.
> HINT: Hints are printed in a new line.
>
> If hint is missing then there is no last line. If the invalid object is a
> field
> or a manager, then the error message starts with
> `app_label.model_label.field_or_manager_name: `. If it's neither a model, a
> manager nor a field, then '?: ' is printed. Do you have any opinion about
> this
> style?
>

Sounds good to me. My only additional comment would be to indent the 2nd+
lines slightly, so that you can easily identify the first lines of a large
number of multi-line errors/warnings. It might also be worth having
different indentation levels for continuation, and for starting the hint.
For example:

app_label.model_label: Error message.
Error message can be multilined. In that case, the first line
should be
a short description and the rest should be a long description.
HINT: Hints are printed in a new line. If hints can be multiline,
then they should also be indented to a new level


Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: manage.py and pyc's

[Chris Church]

It looks like this issue has been marked as wontfix in
https://code.djangoproject.com/ticket/14952

However, I've used the following in manage.py to support running management
commands when distributing only .pyc files:

https://gist.github.com/cchurch/6067733




On Tue, Jul 23, 2013 at 6:29 PM, Jan Vilhuber  wrote:

> In our project, we typically deploy our django app without py's, except
> for a few select ones (manage,py for example). I recently added a few
> management/commands to a few of the apps in my project, and discovered that
> manage.py does not find them, as it looks only for .py files (ignoring
> .pyc's; django.core.management.__init__::29 in django 1.4).
>
> Any reason why this is so? Could commands be discovered by regular python
> introspection rather than looking for py files?
>
> jan
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

manage.py and pyc's

[Jan Vilhuber]

In our project, we typically deploy our django app without py's, except for 
a few select ones (manage,py for example). I recently added a few 
management/commands to a few of the apps in my project, and discovered that 
manage.py does not find them, as it looks only for .py files (ignoring 
.pyc's; django.core.management.__init__::29 in django 1.4).

Any reason why this is so? Could commands be discovered by regular python 
introspection rather than looking for py files?

jan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC] Revamping validation framework and merging django-secure once again

[Christopher Medrela]

Progress: I've implemented registering entry points. Now there is
`django.core.checks.register(callable)` function. There is no
`run_in_development` and `run_in_production` arguments. I've also rewritten
mechanism of triggering checking framework -- `BaseCommand.validate` calls
`django.core.checks.run_checks` instead of `get_validation_errors` (which 
was
deleted) now.

Questions:

1. BaseCommand.validate have an `app` optional argument to run validation 
of a
particular app (if app==None then all checks are performed). Unfortunately, 
with
the current checking framework, we are not able to run checks for a 
particular
app. The attribute isn't used anywhere in Django except for three tests [1] 
and
I don't think that this is heavily used by third party commands. So I 
propose to
deprecate this attribute if it's possible.

[1] 
https://github.com/django/django/blob/master/django/contrib/auth/tests/test_management.py#L176

2a. Warnings are printed with bold, yellow foreground now (errors use red
color). Is it a good choice?

2b. The rules of formatting error messages are that the error message (that 
may
be multiline) is followed by the hint in the next line, i. e.:

app_label.model_label: Error message.
Error message can be multilined. In that case, the first line should be 
a short description and the rest should be a long description.
HINT: Hints are printed in a new line.

If hint is missing then there is no last line. If the invalid object is a 
field
or a manager, then the error message starts with
`app_label.model_label.field_or_manager_name: `. If it's neither a model, a
manager nor a field, then '?: ' is printed. Do you have any opinion about 
this
style?

Now I will focus on moving custom user model checks from Model class to 
auth app
(that should be easy), then rewriting admin checks and finally finishing 
first
iteration (mainly polishing docs).

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Multi-tenancy with different databases

[Fellipe Henrique]

sorry, my bad... :(

On Tuesday, July 23, 2013 3:31:08 PM UTC-3, Andre Terra wrote:
>
> Hi Fellipe,
>
> I'm sorry but you've e-mailed the wrong Google group.
>
> Questions about the use of Django should be directed to django-users, 
> while django-developers is dedicated solely for the development of Django 
> itself.
>
>
> Cheers,
> AT
>
> On Tue, Jul 23, 2013 at 3:23 PM, Fellipe Henrique 
>  > wrote:
>
>> Hi all,
>>
>> I just have problem to use multi-tenancy, with different databases...
>>
>> I have one database, with contains all my users... for each user, I have 
>> a different database to use...
>>
>> How can I do this?  I can't use schemas, because I'm using a legacy 
>> database (firebird) with no support to schemas.
>>
>>
>> My other idea is, each sub-domains have different database.. but, how can 
>> I set for all my django app the default app for each sub-domain?
>>
>> And I think, for me the first options is the ideal!
>>
>>
>> Thanks for all comments..
>>
>> []s
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Multi-tenancy with different databases

[Andre Terra]

Hi Fellipe,

I'm sorry but you've e-mailed the wrong Google group.

Questions about the use of Django should be directed to django-users, while
django-developers is dedicated solely for the development of Django itself.


Cheers,
AT

On Tue, Jul 23, 2013 at 3:23 PM, Fellipe Henrique wrote:

> Hi all,
>
> I just have problem to use multi-tenancy, with different databases...
>
> I have one database, with contains all my users... for each user, I have a
> different database to use...
>
> How can I do this?  I can't use schemas, because I'm using a legacy
> database (firebird) with no support to schemas.
>
>
> My other idea is, each sub-domains have different database.. but, how can
> I set for all my django app the default app for each sub-domain?
>
> And I think, for me the first options is the ideal!
>
>
> Thanks for all comments..
>
> []s
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Multi-tenancy with different databases

[Fellipe Henrique]

Hi all,

I just have problem to use multi-tenancy, with different databases...

I have one database, with contains all my users... for each user, I have a 
different database to use...

How can I do this?  I can't use schemas, because I'm using a legacy 
database (firebird) with no support to schemas.


My other idea is, each sub-domains have different database.. but, how can I 
set for all my django app the default app for each sub-domain?

And I think, for me the first options is the ideal!


Thanks for all comments..

[]s

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Deprecate FCGI support in Django 1.7

[Tim Graham]

Here's a ticket  and pull 
request  for the deprecation.

On Tuesday, July 23, 2013 1:19:28 AM UTC-4, Some Developer wrote:
>
> On 23/07/13 02:07, Curtis Maloney wrote: 
> > Well, having started looking over the flup source, I can see a lot of 
> > useful code to crib, as well as a few critical path bits that can be 
> > optimised [without even reducing readability!] 
> > 
> > So, if you feel like helping out with django-fastcgi ... I'm happy for 
> > the help :) 
> > 
> > -- 
> > Curtis 
>
> Fork it and upload it to Github and then we can see where we stand. 
> Github probably has the best chance of getting people involved with it. 
>
> But yeah I'm available to help. Although I'm back at work next week so 
> my time will be somewhat more limited than it is at the moment. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Custom Chainable QuerySets (#20625)

[Loic Bistuer]

I thought of a third option that I think strikes the right balance between 
convenience and flexibility.

Please see the following comment:

https://github.com/django/django/pull/1328#issuecomment-21400832

-- 
Loic

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Confusion around generic views queryset cloning.

[Hanne Moa]

On 22 July 2013 10:37, Loic Bistuer  wrote:

> I updated the PR to do away with the public `clone()` method.
>
> As long as we have a long-term goal for a `QuerySet.clone()` method, I'm
> happy.
>
> If we plan on changing the cloning behavior, now is effectively a bad time
> to introduce it.
>

No need to change existing ._clone()-behavior. Split what ._clone() does,
have ._clone() use all the new methods, .all() use the methods that it
needs, and .clone() only use the cloning bits. Or do the split and don't
add .clone() yet as it sems we're not quite in agreement. Anyway, plenty of
time to discuss before 1.7.


HM

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Making ".only()" a bit smarter

[Pablo Recio]

Yeah, you might be right. It just feels weird that if I'm trying to fetch
*only* a FK, it needs to do a second lookup. But explicit is better than
implicit indeed.


On 19 July 2013 21:48, Michal Petrucha  wrote:

> On Fri, Jul 19, 2013 at 01:02:34PM +0100, Pablo Recio wrote:
> > Hi devs,
> >
> > I just came up with the following scenario:
> >
> > class A(models.Model):
> > # some fields...
> > b = models.ForeignKey(B)
> >
> > class B(models.Model):
> > # other fields
> >
> > A simple FK relationship. Well, then I wanted to fetch objects from 'A'
> > model but just for retrieve the related 'B', so I tried something like:
> >
> > A.objects.only('b').all()
> >
> > I hoped it was going to be smart enough to check that I'm accessing to FK
> > and then do 'select_related' for that field behind the scenes, but it
> > doesn't, so I needed to chain the select_related myself.
> >
> > Is there any reason for this behaviour? If not, would it be a good patch
> to
> > submit?
>
> Explicit is better than implicit. Also, special cases aren't special
> enough to break the rules.
>
> To me, what you propose seems too arbitrary. `only` would do what it
> says it does, that is, defer everything but the selected fields,
> except for the special case where you restrict the query to a single
> ForeignKey, in which case it would also do a `select_related` -- that
> sounds like a quite specific special case.
>
> Also, what would you propose to happen in case you do `defer` on all
> fields except one ForeignKey? Would that do the same thing as the
> equivalent `only` or not? Why?
>
> In other words, I don't think it is worth complicating the API in this
> way just to save a single method call on a QuerySet.
>
> Michal
>



-- 
Pablo Recio Quijano

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.