Re: Annotation failure (Combining multiple aggregations)

[Anssi Kääriäinen]

On Tuesday, December 8, 2015 at 5:28:08 PM UTC+2, Michael wrote:
>
> On Tuesday, December 8, 2015 at 1:26:52 AM UTC-6, Anssi Kääriäinen wrote:
>>
>>
>> Come to think of it, we already have a workaround:
>>Book.objects.annotate(author_cnt=RawSQL("(select count(*) from author 
>> where author.book_id = book.book_id)").
>>
>
> Yes, you can do a subquery to get the Sum or Count but then you cannot 
> "filter": `qs.filter(author_cnt__gt=0)` won't work.
>
> I think it would require the correct "GROUP BY" and "HAVING" clause to be 
> able to filter, correct?
>

This one actually does work with filter(). As the count is inside a 
subselect, it can be used directly in the WHERE clause without GROUP BY or 
HAVING. Using a direct count without a subselect wouldn't work.

 - Anssi

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f7516a98-5be5-49ba-8e40-1a49e95b9537%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Annotation failure (Combining multiple aggregations)

[Anssi Kääriäinen]

On Tuesday, December 8, 2015 at 2:52:07 PM UTC+2, Josh Smeaton wrote:
>
> Yeah I'm wary that a lot of the problems with extra() will be replicated 
> by users switching to RawSQL() instead. It won't handle realiasing or group 
> by correctly.
>

The group by case we can fix by creating a separate RawAggregate class, or 
by adding aggregate flag to RawSQL. The hardcoding of column and table 
names, and the realisasing problem can be solved with refsql style 
annotations: qs = Author.objects.annotate( casewhen=RefSQL("case when {
{name}} = %s then height else weight end", ('Anssi',), 
  output_field=models.IntegerField()) ).order_by('name')(from 
https://github.com/akaariai/django-refsql/blob/master/testproject/testproject/tests.py).

The idea is quite simply that instead of using hardcoded table.col 
references in the code, you use normal Django lookups, and refsql converts 
those to Col expressions.

But, whenever possible we should provide real expressions.

  - Anssi

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5c5d7dd2-16fa-4495-8d3d-e6395b01681c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[martin f krafft]

also sprach Shai Berger  [2015-12-09 01:20 +0100]:
> class Parent(Model):
>   content_type = ForeignKey('ContentType')
> 
> class Child(Model):
>   parent = ForeignKey(Parent)
>   object_id = IntegerField()
>   # The next does not exist and they want it
>   egfk = ExtendedGenericForeignKey('parent__content_type', 'object_id')

Precisely.

> I suspect that this is a little too baroque for django core, and
> further, it should be possible to implement in user code. Note
> that GenericForeignKey itself is not part of Django core, but
> a contrib app;

Yes, and as noted in my initial mail: I wasn't even sure if turning
to this list was the right thing to do.

> there should be no reason why you cannot do what it does (with the
> only possible exception being admin support).

Yes, I have it all implemented, but it just seems like I am hacking
and duplicating code and it feels aweful. Thus my itch to make the
upstream code more flexible.

> If you try to do that and find that you are missing something, or
> need to use undocumented, private APIs, you'll have a very strong
> case for having those problems solved.

Isn't this enough:

  
https://github.com/django/django/blob/stable/1.9.x/django/contrib/contenttypes/fields.py#L151

It hardcodes the class object and thereby prevents any
subclassing/specialisation/extension, and it's not at all how Python
was designed to work. I understand that the checks framework
requires one to step beyond simple Python duck-typing, but I am not
sure I can be convinced that it's necessary to enforce a specific
model class, when all you need to make sure is that the related
object exposes a specific interface.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"this week dragged past me so slowly;
 the days fell on their knees..."
-- david bowie
 
spamtraps: madduck.bo...@madduck.net

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151209040738.GB4130%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[martin f. krafft]

also sprach Florian Apolloner  [2015-12-08 23:38 +0100]:
> but if it were for me GFK would have a special case in hell.

How would you implement LogEntries without GFKs?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"as if you could kill time without injuring eternity."
  -- henry david thoreau
 
spamtraps: madduck.bo...@madduck.net

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151209040123.GA4130%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[martin f. krafft]

also sprach Tim Graham  [2015-12-08 22:38 +0100]:
> I'm having trouble understanding the problem. Could you give some example 
> models and code that demonstrates it?

Gladly. The code I am talking about is here:

  https://github.com/madduck/wafer/blob/147-kvpairs/wafer/kvpairs/models.py
  https://github.com/madduck/wafer/blob/147-kvpairs/docs/kvpairs.rst

but I'll try to give the quick rundown here too:

Basic requirement: avoid creating new database fields for all the
various random needs around conference management. In the past, we'd
add to the UserProfile fields to hold t-shirt size, payment and
arrival status, day trip participation etc. and the database just
grew and grew. We're now switching to this new "wafer" and would
like to ensure that this doesn't happen again.

So while there are some profile attributes for sure that are core
and will go into the profile table, others aren't and we'd really
rather treat them as throw-away, quick'n'dirty data, which they
often are.

Hence I created this key-value store. At the core, it just attaches
two text fields "key" and "value" to an instance of a model (e.g.
a scheduled talk), and GenericForeignKey would be just perfect for
this.

But we also wanted to collect a bit of information about a Key and
add a bit more structure. For the moment, Key instances just hold
information about owner and group for access control and
namespacing, and, well, the model to which this key applies (also
used for namespacing).

Here's what it looks like:

   +-- ContentType --+   +-- Key +  1+-- KVPair --+
   | ID  |-. | ID|---. n | ID |
   | app_label   |  \1   | owner |`--| object_id  |
   | model   |   \   | group |.--| ref_id |
   | name|   n\  | name  |   n|  | value  |
   +-+ `-| content_t ||  ++
 +---+|
 1|  +-- Talk --+
  `--| ID   |
 | title|
 + … ---+

The problem is that GenericForeignKey expects content_type and
object_id to be in the KVPair model, but content_type is in the Key.
There's still a 1:n relation between ContentType and KVPair, but
it's indirect.

You might rightfully ask why we don't just throw the Key fields into
KVPair and be done with it. Sure, that is a solution, but you'll
also concur that it'll involve a lot of duplicate data and make
unique constraints a lot harder. It'd seem a workaround at best for
the limitations around GenericForeignKey.

But if GenericForeignKey could just be appeased by telling it "yes
I know you want content_type in the same model, but trust me, if you
use the attribute of this related object, you'll get the same", then
it'd work out.

To me, the even better solution would be to give Key the right
accessors to make GenericForeignKey happy, such that GFK doesn't
even need to care about what kind of object it's being asked to
refer to, as long as it gets the data it needs. I have toyed with
the idea of making Key a subclass of ContentType, but that creates
a slew of other problems, and doesn't address the fact tat
GenericForeignKey actually compares the instance class with the
hard-coded string "contenttypes.GenericForeignKey".

Does this make more sense?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
an egg has the shortest sex-life of all: if gets laid once; it gets
eaten once. it also has to come in a box with 11 others, and the
only person who will sit on its face is its mother.
 
spamtraps: madduck.bo...@madduck.net

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151209035904.GA13218%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[Shai Berger]

On Tuesday 08 December 2015 23:38:26 Tim Graham wrote:
> I'm having trouble understanding the problem. Could you give some example
> models and code that demonstrates it?
> 

If I get things right:

class Parent(Model):
content_type = ForeignKey('ContentType')

class Child(Model):
parent = ForeignKey(Parent)
object_id = IntegerField()
# The next does not exist and they want it
egfk = ExtendedGenericForeignKey('parent__content_type', 'object_id')

I suspect that this is a little too baroque for django core, and further, it 
should be possible to implement in user code. Note that GenericForeignKey 
itself is not part of Django core, but a contrib app; there should be no 
reason why you cannot do what it does (with the only possible exception being 
admin support).

If you try to do that and find that you are missing something, or need to use 
undocumented, private APIs, you'll have a very strong case for having those 
problems solved.

Of course, if this is not what you had in mind, please correct my 
misunderstanding.

HTH,
Shai.

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[Florian Apolloner]

In addition to what Tim already said, I think the acceptance of a patch on 
such a feature would depend on the (quality of the) patch itself. I am not 
going to spelk for the whole core team here, but I think most of the people 
in the core team try to avoid generic FKs for plenty of reasons. As such a 
change in this area might have better chances with an existing patch 
showing what you are trying to achieve. I know, that this puts a lot of 
pressure on you, or at least asks for work which might soon be forgotten -- 
but if it were for me GFK would have a special case in hell.

Cheers,
Florian

On Tuesday, December 8, 2015 at 2:10:51 PM UTC+1, martin f krafft wrote:
>
> Hello, 
>
> I hope this is the right place to bring up the following idea, even 
> if it's in django.contrib.contenttypes. 
>
> GenericForeignKeys currently hard-require a model to have 
> a ForeignKey field to the ContentType model. In a specific use-case, 
> we're experiencing a bit of trouble with this, because the 
> ContentType in our case is actually indirectly available via another 
> ForeignKey: 
>
>   MyModel → n:1 → ParentModel → n:1 → ContentType 
>
> However, contenttypes cannot be convinced to access the extra level 
> of indirection and complains that MyModel.ForeignKey('ParentModel') 
> is not a ForeignKey('ContentType'). 
>
> Despite the additional query overhead, it'd be great if instead 
> I could tell contenttypes that it should 
>
>   either 
>   (a) look beyond the current model for the actual content_type 
>   attribute, e.g. content_type='myattribute.content_type', 
>   which, if myattribute is a ForeignKey itself adds a level of 
>   indirection but doesn't change the logic and causes 
>   contenttypes to resolve myattribute and use the content_type 
>   field on the result, 
>
>   or 
>   (b) avoid hard-coding the dependency on ContentType and instead 
>   duck-type the argument, such that my parent model could expose 
>   the necessary functionality, e.g. via proxy calls to the 
>   ForeignKey on ContentType stored in the parent. 
>
> Does this make sense? Would it be worthwhile to start working on 
> a patch for this? Which of (a) or (b) would be preferred? It feels 
> to me that while (b) is the Pythonesque way, (a) is more Django… 
>
> Looking forward to your thoughts, 
>
> -- 
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ 
>   
> warning: dates in calendar are closer than they appear. 
>   
> spamtraps: madduc...@madduck.net  
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1f36b7b5-4ec5-42fa-a6ba-d62f90cad9b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GenericForeignKey: loosening the requirements on the ContentType reference

[Tim Graham]

I'm having trouble understanding the problem. Could you give some example 
models and code that demonstrates it?

On Tuesday, December 8, 2015 at 8:10:51 AM UTC-5, martin f krafft wrote:
>
> Hello, 
>
> I hope this is the right place to bring up the following idea, even 
> if it's in django.contrib.contenttypes. 
>
> GenericForeignKeys currently hard-require a model to have 
> a ForeignKey field to the ContentType model. In a specific use-case, 
> we're experiencing a bit of trouble with this, because the 
> ContentType in our case is actually indirectly available via another 
> ForeignKey: 
>
>   MyModel → n:1 → ParentModel → n:1 → ContentType 
>
> However, contenttypes cannot be convinced to access the extra level 
> of indirection and complains that MyModel.ForeignKey('ParentModel') 
> is not a ForeignKey('ContentType'). 
>
> Despite the additional query overhead, it'd be great if instead 
> I could tell contenttypes that it should 
>
>   either 
>   (a) look beyond the current model for the actual content_type 
>   attribute, e.g. content_type='myattribute.content_type', 
>   which, if myattribute is a ForeignKey itself adds a level of 
>   indirection but doesn't change the logic and causes 
>   contenttypes to resolve myattribute and use the content_type 
>   field on the result, 
>
>   or 
>   (b) avoid hard-coding the dependency on ContentType and instead 
>   duck-type the argument, such that my parent model could expose 
>   the necessary functionality, e.g. via proxy calls to the 
>   ForeignKey on ContentType stored in the parent. 
>
> Does this make sense? Would it be worthwhile to start working on 
> a patch for this? Which of (a) or (b) would be preferred? It feels 
> to me that while (b) is the Pythonesque way, (a) is more Django… 
>
> Looking forward to your thoughts, 
>
> -- 
> @martinkrafft | http://madduck.net/ | http://two.sentenc.es/ 
>   
> warning: dates in calendar are closer than they appear. 
>   
> spamtraps: madduc...@madduck.net  
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/934950d5-f51e-46f0-ad71-3ef4151ed8bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Annotation failure (Combining multiple aggregations)

[Michael]

On Tuesday, December 8, 2015 at 1:26:52 AM UTC-6, Anssi Kääriäinen wrote:
>
>
> Come to think of it, we already have a workaround:
>Book.objects.annotate(author_cnt=RawSQL("(select count(*) from author 
> where author.book_id = book.book_id)").
>

Yes, you can do a subquery to get the Sum or Count but then you cannot 
"filter": `qs.filter(author_cnt__gt=0)` won't work.

I think it would require the correct "GROUP BY" and "HAVING" clause to be 
able to filter, correct?


-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df291acb-a1cb-4afa-9310-1f0166c6bb0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GenericForeignKey: loosening the requirements on the ContentType reference

[martin f krafft]

Hello,

I hope this is the right place to bring up the following idea, even
if it's in django.contrib.contenttypes.

GenericForeignKeys currently hard-require a model to have
a ForeignKey field to the ContentType model. In a specific use-case,
we're experiencing a bit of trouble with this, because the
ContentType in our case is actually indirectly available via another
ForeignKey:

  MyModel → n:1 → ParentModel → n:1 → ContentType

However, contenttypes cannot be convinced to access the extra level
of indirection and complains that MyModel.ForeignKey('ParentModel')
is not a ForeignKey('ContentType').

Despite the additional query overhead, it'd be great if instead
I could tell contenttypes that it should

  either
  (a) look beyond the current model for the actual content_type
  attribute, e.g. content_type='myattribute.content_type',
  which, if myattribute is a ForeignKey itself adds a level of
  indirection but doesn't change the logic and causes
  contenttypes to resolve myattribute and use the content_type
  field on the result,

  or
  (b) avoid hard-coding the dependency on ContentType and instead
  duck-type the argument, such that my parent model could expose
  the necessary functionality, e.g. via proxy calls to the
  ForeignKey on ContentType stored in the parent.

Does this make sense? Would it be worthwhile to start working on
a patch for this? Which of (a) or (b) would be preferred? It feels
to me that while (b) is the Pythonesque way, (a) is more Django…

Looking forward to your thoughts,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
warning: dates in calendar are closer than they appear.
 
spamtraps: madduck.bo...@madduck.net

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151208043528.GA13918%40fishbowl.rw.madduck.net.
For more options, visit https://groups.google.com/d/optout.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Annotation failure (Combining multiple aggregations)

[Josh Smeaton]

Yeah I'm wary that a lot of the problems with extra() will be replicated by 
users switching to RawSQL() instead. It won't handle realiasing or group by 
correctly.

On Tuesday, 8 December 2015 18:26:52 UTC+11, Anssi Kääriäinen wrote:
>
>
>
> On Tuesday, December 8, 2015 at 3:16:20 AM UTC+2, Michael wrote:
>>
>> I have the same problem.
>>
>> I tried to use `extra` but then I can't filter so it's not the best.
>>
>> Anybody has more info or a workaround?
>>
>
> Come to think of it, we already have a workaround:
>Book.objects.annotate(author_cnt=RawSQL("(select count(*) from author 
> where author.book_id = book.book_id)").
> The fact that you can do subselects with models.RawSQL is something that a 
> lot of users seem to miss. There are a couple of reasons why one shouldn't 
> use RawSQL too much, like the way it hard codes column names and table 
> aliases.
>
>  - Anssi
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/29a5a198-28c5-4339-9786-cd3d5e799b81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Split DeleteView into a more generic ConfirmView

[Marc Tamlyn]

Hi Lennart,

I certainly like the idea and have written at least two implementations of
`ConfirmView` in my projects before. Without getting into specifics, I'm
not sure how we feel about adding more generic views like this, even where
it does make sense. To me a good initial course of action could be to
consider integrating it with django-braces. They have a collection of
common mixins for common or fairly common CBV patterns. In fact we have
already merged commonly used parts of django-braces into contrib.auth for
1.9.

Marc

On 7 December 2015 at 20:28, Lennart Buit  wrote:

> I should add patches that I promise to add ;)
>
> --Lennart
>
>
> On Monday, December 7, 2015 at 9:23:19 PM UTC+1, Lennart Buit wrote:
>>
>> Hey all,
>>
>> One of my minor annoyances with the class based view system in django is
>> that there is no clear way to model a confirmable action. The concept does
>> exists in cbv, but only for deleting objects. I however think that there
>> are more usages for confirming actions other then delete.
>>
>> Lets look at an example, a news site can CRUD newsaticles. But this news
>> site has some articles for free, and some other behind a paywall. Also,
>> editors on this site can publish newsarticles (after which they come in the
>> pay section), and then promote them to free articles. The views in django
>> would then look as follows (with some brevity):
>>
>> # This also goes for Update/Delete/...
>> class NewsArticleCreateView(CreateView):
>> model = NewsArticle
>>
>> # This also goes for Promote
>> class NewsArticlePublishView(DetailView):
>> model = NewsArticle
>> success_url = 'somewhere'
>>
>> def post(self, *args, **kwargs):
>> self.object = self.get_object()
>> success_url = self.get_success_url()
>> self.object.published = True
>> self.object.save()
>>
>> return HttpResponseRedirect(success_url)
>>
>> def get_success_url(self):
>> if self.success_url:
>> return self.success_url.format(**self.object.__dict__)
>> else:
>> raise ImproperlyConfigured(
>> "No URL to redirect to. Provide a success_url.")
>>
>> The problem, I think, is that we are copying most of a DeleteView for a
>> fairly standard confirmable action. The get_success_url function is almost
>> the same, and most of the code found in the post function is that of delete
>> in DeleteView. I think therefore that we should consider splitting the
>> DeleteMixin in a more generic ConfirmMixin, make DeleteMixin a subclass of
>> ConfirmMixin, and introduce the (more) generic BaseConfirmView and
>> ConfirmView. The above example will then look as follows:
>>
>> class NewsArticlePublishView(ConfirmView):
>> model = NewsArticle
>> success_url = 'somewhere'
>>
>> def action_confirmed(self):
>> self.object.published = True
>> self.object.save()
>>
>> I think the benefits of this solution are clear, we introduce readability
>> in these types of views (look at the class declaration, its a confirm view
>> alright!) at the cost of library size (another 3 classes got added).
>>
>> Please be gentle, I am new here ;). But, I enjoy a technical discussion!
>> And I attached a patch that implement this proposal, it however should be
>> treated as a POC, not a complete implementation with tests and docs and
>> such.
>>
>> --Lennart
>>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16df2f54-fee9-4b5d-9882-bc9954a5c8dd%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1FAq3USc3oUUnitCTDpquq%2B_UDJySt%2BUhM41VRN%2B89G_w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 shipping invalid .py files in the startapp template

[Raphael Hertzog]

Hello,

I'm another Debian developer co-maintaining Django in Debian.

Le lundi 30 novembre 2015, Florian Apolloner a écrit :
> I am not against including it, but depending on how packaging works in 
> Debian it could be possible to call pycompile with a proper exclusion list 
> instead. The PR itself only works by accident, there are also files in 

We can always add many exceptions but in the end any distro packager wants
to avoid exceptions as we want to automate as much as possible
installations of Python modules (and update to new upstream versions
to make them quickly available to users).

There's a case to be made that the whole process should probably not loose the
information coming setup.py but I'd argue that this information is not
really useful information for packagers until it's properly stored in the
filesystem by the module installation process.

And I would also argue that this would then need to be fixed at the Python
level so that Data is actually stored in separate directories
(/usr/share/something) and not mixed up with Python code.

All in all, I believe our request to be reasonable and I would like
you to consider applying Chris's PR or similar code.

Thank you!

> That said, the amount of issues I have seen in #django due to the 
> debundling of pip in debian/ubuntu is not something I can count on one hand 
> anymore. Most of the time I just gave up and suggested to install pip 
> manually, all problems gone. The syntax error has popped up three times so 
> far (iirc) and requires no fixing aside from educating people.

I find it weird to have such feelings when you go to such lengths to
implement a very nice LTS support policy for Django itself.

Cheers,
-- 
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20151208082148.GB23223%40home.ouaza.com.
For more options, visit https://groups.google.com/d/optout.