Re: Widening participation (Thoughts from DjangoCon)

[Tom Forbes]

Regarding Gitlab: I love gitlab and for organizations it's one of if not
the best tools in its space. But it falls down for projects like Django,
and I don't think moving migrating the code from GitHub is a good idea.

The labels would need automating, which would require a GitHub bot of some
kind. The workflow could be as simple as "new tickets are assigned the
awaiting review tag" and "only members of the Django org can modify tags"?


On Tue, 11 Dec 2018, 19:38 Josh Smeaton  For what it's worth, I agree. I think we should consider using GitHub
> issues. I don't think there's anything in Trac, from a user perspective,
> that we couldn't really do with Issues. The main issue, I think, would be
> allowing non-committers (organisational members) to triage tickets and
> change the ticket status.
>
> But I don't have the time to plan or champion a change like that through
> these days, so while I'd like to see it happen, I'm not the person to push
> for it to happen.
>
> Jamesie: please see "Why not Gitlab?" [0]. While it might be better from a
> technical standpoint, it would not be better than GH Issues from an
> onboarding perspective.
>
> [0]https://www.python.org/dev/peps/pep-0581/#why-not-gitlab
>
> On Tuesday, 11 December 2018 23:20:21 UTC+11, Tom Forbes wrote:
>>
>> > The only reason Github issues would be a consideration is if the group
>> thought the onboarding experience (being where users already are with a
>> tool they're already familiar with) would have more value than sticking
>> with with the status quo which is strictly better from a feature
>> perspective than GH Issues
>>
>> I really think it's worth considering - I'm not convinced Trac is
>> strictly better from a feature perspective. Things like the dashboards are
>> interesting, sure, but what does it do that Github issues don't? And by
>> this I don't mean features that exist but we don't use, I mean our general
>> ticket workflow that 99% of contributors are exposed to. There are far
>> larger projects than Django currently using Github issues successfully and
>> they have a far more complex workflow including CLA's, high-granularity
>> tags, automatic reviewer selection, automatic closing, etc etc.
>>
>> The cost of a migration would not be cheap, but is it worth doing a
>> formal evaluation and consider it? The "why Github section" (
>> https://www.python.org/dev/peps/pep-0581/#why-github) in that PEP lists
>> some good reasons that apply to us as well. The key one for me is lowering
>> the barrier to entry which I think we should be aiming towards. If we are
>> looking to expand the development group and get more people onboard we may
>> need to shake things up, as the status quo is problematic in that area.
>>
>> On 11 December 2018 at 12:04:32, Josh Smeaton (josh.s...@gmail.com)
>> wrote:
>>
>> I don't think something like Jira would even be a consideration.
>>
>> The only reason Github issues would be a consideration is if the group
>> thought the onboarding experience (being where users already are with a
>> tool they're already familiar with) would have more value than sticking
>> with with the status quo which is strictly better from a feature
>> perspective than GH Issues. Incrementally improving Trac can improve the
>> value prop for not changing, but I don't think anyone that actually uses
>> Trac would say it's worse from a feature perspective. Even if that value
>> judgement did land on GH issues side, there would still be a large
>> operational undertaking to make that transition.
>>
>> Again, the PEP for doing this for CPython would be very similar for
>> Django, so please refer to https://www.python.org/dev/peps/pep-0581/ for
>> some examples of why and what operational concerns there can be (migration,
>> permissions, etc).
>>
>> On Tuesday, 11 December 2018 07:26:58 UTC+11, Ira Abbott wrote:
>>>
>>> Apologies for the double post - my last one was not clear.  "just that"
>>> means that the payment is intended to indicate that it is worth a JIRA
>>> license to me to not use JIRA.
>>>
>>> This group does great things.  I am sure that the group can come up with
>>> some interesting ways to scale that will ultimately benefit the framework
>>> as a whole.
>>>
>>> On Monday, December 10, 2018 at 3:21:53 PM UTC-5, Ira Abbott wrote:

 FWIW: Please consider my contribution of $84 (one bulk JIRA license for
 one year) to be just that.

 On Monday, December 10, 2018 at 2:14:07 PM UTC-5, Zachary Garwood wrote:
>
> I'd pay money to NOT use Jira.
>
> On Mon, Dec 10, 2018, 11:09 AM Dan Davis 
>> Tom, you are right about the UX issues, but full-text and inverted
>> indexing would help with the responsiveness as well.  Technically, I was
>> talking about djangoproject's TracSearch
>> .  That's closer to good UX
>> as well, because you can get there by progressive enhancement rather than
>> taking stuff away.
>>
>> You are al

Re: PEP 484 type hinting in Django

[Carlton Gibson]

Hi all. 


Where are we with this Type Hinting work? 


I just closed https://code.djangoproject.com/ticket/30019 as needsinfo 
pointing back to this thread. 


As far as I can see: 

* There's keenness for this. 
* There's a number of people who are prepared to put in the effort. 
* But we just need a strategy. 

It looks then like a coordination problem. Do we just need to get said 
people in a (virtual) room...? 

Maybe one of you — anyone — opening a DEP to begin the conversation would 
be enough.. 
(That's just an idea.) 

Looking here: 
https://github.com/django/deps/blob/master/final/0001-dep-process.rst#dep-submission-workflow
I'd guess "Forming the Team" is relevant. 

Happy to help if I can. 
(I recall Frank mentioned it no too long ago...) 

Kind Regards,

Carlton

-- 
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/094379ab-8a7b-405e-a31a-e3711a118d89%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Allow contrib.sites to use the request host and fallback to a SITE_ID

[Carlton Gibson]

Hi Ira, 

Thanks for your post. I wasn't able to follow your use-case exactly:

On Monday, 10 December 2018 13:47:54 UTC+1, Ira Abbott wrote:
>
> We all learn very early in playing with django to set a site and a 
> SITE_ID.  Once we operate as multiple sites, we either use the multiple 
> processes, each configured with a separate SITE_ID or we can now pass a 
> request in.  However,  I assume for backward compatibility, SITE_ID must be 
> removed.  This allows all sites which specify SITE_ID to operate as if the 
> addition of passing request was not added.  However, removing SITE_ID to 
> allow get_site_by_request breaks all applications which do NOT pass 
> request, because there is no SITE_ID.
>

Can you explain your example more fully please? 

Thanks. 

Kind Regards,

Carlton
 

-- 
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/0d00489a-4f6c-4826-90da-4454219e1bed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django self reference (FK) change SQL result

[igor malinov]

Good day for Everyone.
Because I have self-reference, my queryset no work properly
I have a model


class Agency(Organization):
organization_ptr = models.OneToOneField(to='Organization', 
parent_link=True, primary_key=True, related_name='%(class)s', serialize=False, 
on_delete=CASCADE)
accreditation = models.OneToOneField('Accreditation', null=True, 
blank=True, on_delete=DO_NOTHING)
parent = models.ForeignKey("self", null=True, blank=True, 
on_delete=SET_NULL)  



class Application(models.Model):
id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False)

name = models.CharField(max_length=255)

seers = models.ManyToManyField('Agency', blank=True, 
through='ApplicationAgencySeer')

# and other



class ApplicationAgencySeer(models.Model):
application = models.ForeignKey(Application, on_delete=models.CASCADE)
agency = models.ForeignKey('Agency', on_delete=models.CASCADE)
status = models.IntegerField('Status', choices=CHOICE)
created = models.DateTimeField(auto_now_add=True)




Now I wanna exclude (simple query)

a = 
Application.objects.exclude(seers__agency__id='9e71cff4-443d-4c60-ac2d-9dcca2a9c147')
print(a.query)


" * "  change by myself

SELECT *
FROM "myapp_application"
WHERE NOT ("myapp_application"."id" IN (SELECT U1."application_id"
   FROM "myapp_applicationagencyseer" U1
  INNER JOIN "myapp_agency" U2 
ON (U1."agency_id" = U2."organization_ptr_id")
  INNER JOIN "myapp_agency" U3 
ON (U2."organization_ptr_id" = U3."parent_id")
   WHERE U3."organization_ptr_id" = 
'9e71cff4-443d-4c60-ac2d-9dcca2a9c147'))
ORDER BY "myapp_application"."created_date" DESC;


result


application_id

7d83d056-5a7d-4095-9037-98bde29a3d78otherfields...otherfields..

7cb60afc-109d-4570-ad24-6cad6b7ddd9aotherfields...otherfields.. 
  <-- this row error



exclude - no really exclude
Invoked problem by `INNER JOIN "myapp_agency" U3 ON (U2.
"organization_ptr_id" = U3."parent_id")`

--return 0

(SELECT U1."application_id"
FROM "myapp_applicationagencyseer" U1
INNER JOIN "myapp_agency" U2 ON (U1."agency_id" = U2."organization_ptr_id")
INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" = U3."parent_id")
WHERE U3."organization_ptr_id" = '9e71cff4-443d-4c60-ac2d-9dcca2a9c147')


--althouth I have  myapp_applicationagencyseer

id   created   agency_id
   application_id status

1   2018-12-10 17:41:14.272684  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
7cb60afc-109d-4570-ad24-6cad6b7ddd9a1
2   2018-12-11 19:25:58.818000  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
7cb60afc-109d-4570-ad24-6cad6b7ddd9a0


-- myapp_agency

organization_ptr_idaccreditation   parent

aff44d42-ce81-4c3e-b6e1-056ed9351adbNull   Null

9e71cff4-443d-4c60-ac2d-9dcca2a9c14710АА71 Null   <-- It have 
Null parent



Why Query have `INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" = 
U3."parent_id")` . 

-- 
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/de52c7d8-b05e-4266-8ab8-146f098ac5d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Allow contrib.sites to use the request host and fallback to a SITE_ID

[Ira Abbott]

Hi Carlton,

Thanks for taking the time to investigate.  I specifically tried to 
generalize for this forum as I believe the underlying behaviour for which I 
am proposing change is fundamental enough to warrant attention but this 
group.

My specific use case involves allauth and dbtemplates, two pip packages 
that I have run together with SITE_ID set.  I am expanding, or attempting 
to, to support 'ephemeral sites', which can be skinned via templates stored 
in dbtemplates.  So just remove SITE_ID, right?

That would be the case if dbtemplats supported request based site lookup, 
however the template loader portion really cannot and shouldn't be burdened 
with request context as it can and should be accessible without it.  So, I 
either 'down-shift' to SITE_ID and gear up on processes, or I look for a 
code solution, which is more fun for me :)  As always, there are many ways 
to remove the fur from a feline.

One real-world example of what I hope to be ablate achieve would be support 
a team or Realtors (tm) who purchase domains for each property sold, with 
the potential to skin each according to the domain.  I fired up dbtemplates 
which has a lot of good stuff, but run in to the fact that it requires 
SITE_ID.  Yes, I am also pursuing the 'fix dbtemplates' route, or find 
something else, or make it myself, but experience says that this will not 
be the last time I or others try to pull in pieces that conflict.  I 
believe this proposal would provide a means of resolution in which none of 
the packages need to be tweaked to get them to play nicely together when 
one makes valuable use of request by site and another does not allow it.

I posted (not yet approved) a companion topic to django-users for the 
purposes of how to work with this for existing releases, best practices for 
'overloading' django and apps, etc. (running with patches / tweaks, etc). 
 I can tweak up dbtemplates to not call for get_current() if no SITE_ID is 
present, but return a configuration, I can tweak up django and run a fork.  

To bring this back around to justification for a change to such a large 
install base based on my current understanding:
- These two modes of operation for site managers are incompatible.
- pip is one of the top for repos and django is a major player in that 
space - the number of django packages is impressive. I see the rear-view 
roadmap as a natural progression and the addition of the request mech as a 
good example of 'first do no harm'.  However now that we have had two for a 
while, I will not be the last person to try to move from SITE_ID to request 
based sites and find packages that don't play together nicely.  At least I 
don't think I'm that unique.
- The change is designed to continue wit the 'first do no harm' strategy, 
so the first requirement is that all existing settings files in the install 
base work with exactly the same behaviour as previously.  I believe this is 
baked in to the suggested implementation.

I'm actually surprised that I didn't  'We decided XYZ back in ticket 123'.

I hope I am not just missing something fundamental, I am not an expert with 
this framework by any stretch of the imagination, mine included.  The 
specific behaviour does seem to be quite limited in scope, however.  You 
either do or do not have SITE_ID - if you have it, you get SITE_ID even if 
you pass in request.  If you do not have SITE_ID, then you MUST pass 
request, or an exception is thrown.  Never shall the twain meet, unless you 
have another piece of information and another check.

That much seems very isolated.  The ability to allow one portion of code to 
get some default site id while allowing others to get the the id based on 
the request seems like a reasonable enough thing to want to do when 
generalized.  At least that't the way it seems to me, so I thought I would 
offer these puny few lines of code back with gratitude for the multitudes 
of code that came before.

Again, thank you for your consideration and all of the work done by 
everyone.

Regards,

Ira







On Wednesday, December 12, 2018 at 11:18:36 AM UTC-5, Carlton Gibson wrote:
>
> Hi Ira, 
>
> Thanks for your post. I wasn't able to follow your use-case exactly:
>
> On Monday, 10 December 2018 13:47:54 UTC+1, Ira Abbott wrote:
>>
>> We all learn very early in playing with django to set a site and a 
>> SITE_ID.  Once we operate as multiple sites, we either use the multiple 
>> processes, each configured with a separate SITE_ID or we can now pass a 
>> request in.  However,  I assume for backward compatibility, SITE_ID must be 
>> removed.  This allows all sites which specify SITE_ID to operate as if the 
>> addition of passing request was not added.  However, removing SITE_ID to 
>> allow get_site_by_request breaks all applications which do NOT pass 
>> request, because there is no SITE_ID.
>>
>
> Can you explain your example more fully please? 
>
> Thanks. 
>
> Kind Regards,
>
> Carlton
>  
>

-- 
You received this message

Re: Django self reference (FK) change SQL result

[Ira Abbott]

A few questions:

You are posting this example because you believe you have found a bug in 
django, correct?  Otherwise, please post to the users group.

The behavioral problem described is "exclude - no really exclude", 
correct?  You perform an exclusion and do not see the exclusion and then 
show the queryset.

I am not an expert, but I believe the reason the exclude is not working 
might be that 'id' as a field of Agency is not a UUID.  The UUID primary 
key is in Applications.  Agency would  have an 'id' as a built in Primary 
key, but it will be an integer.  Since the primary key for Agency is a 
OneToOne (unique ForeignKey), I suspect, but do not know that id as a 
built-in member may follow.  Either way it is probably not a UUID and will 
not match for exclusion.

On initial inspection, I doubt this example is inappropriate behavior.

Regards,

Ira


On Wednesday, December 12, 2018 at 2:42:05 PM UTC-5, igor malinov wrote:
>
> Good day for Everyone.
> Because I have self-reference, my queryset no work properly
> I have a model
>
>
> class Agency(Organization):
> organization_ptr = models.OneToOneField(to='Organization', 
> parent_link=True, primary_key=True, related_name='%(class)s', 
> serialize=False, on_delete=CASCADE)
> accreditation = models.OneToOneField('Accreditation', null=True, 
> blank=True, on_delete=DO_NOTHING)
> parent = models.ForeignKey("self", null=True, blank=True, 
> on_delete=SET_NULL)  
>
>
>
> class Application(models.Model):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4, 
> editable=False)
>
> name = models.CharField(max_length=255)
>
> seers = models.ManyToManyField('Agency', blank=True, 
> through='ApplicationAgencySeer')
>
> # and other
>
>
>
> class ApplicationAgencySeer(models.Model):
> application = models.ForeignKey(Application, on_delete=models.CASCADE)
> agency = models.ForeignKey('Agency', on_delete=models.CASCADE)
> status = models.IntegerField('Status', choices=CHOICE)
> created = models.DateTimeField(auto_now_add=True)
>
>
>
>
> Now I wanna exclude (simple query)
>
> a = 
> Application.objects.exclude(seers__agency__id='9e71cff4-443d-4c60-ac2d-9dcca2a9c147')
> print(a.query)
>
>
> " * "  change by myself
>
> SELECT *
> FROM "myapp_application"
> WHERE NOT ("myapp_application"."id" IN (SELECT U1."application_id"
>FROM "myapp_applicationagencyseer" 
> U1
>   INNER JOIN "myapp_agency" 
> U2 ON (U1."agency_id" = U2."organization_ptr_id")
>   INNER JOIN "myapp_agency" 
> U3 ON (U2."organization_ptr_id" = U3."parent_id")
>WHERE U3."organization_ptr_id" = 
> '9e71cff4-443d-4c60-ac2d-9dcca2a9c147'))
> ORDER BY "myapp_application"."created_date" DESC;
>
>
> result
>
>
> application_id
>
> 7d83d056-5a7d-4095-9037-98bde29a3d78otherfields...otherfields..
>
> 7cb60afc-109d-4570-ad24-6cad6b7ddd9aotherfields...otherfields..   
> <-- this row error
>
>
>
> exclude - no really exclude
> Invoked problem by `INNER JOIN "myapp_agency" U3 ON (U2.
> "organization_ptr_id" = U3."parent_id")`
>
> --return 0
>
> (SELECT U1."application_id"
> FROM "myapp_applicationagencyseer" U1
> INNER JOIN "myapp_agency" U2 ON (U1."agency_id" = U2."organization_ptr_id")
> INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" = U3."parent_id")
> WHERE U3."organization_ptr_id" = '9e71cff4-443d-4c60-ac2d-9dcca2a9c147')
>
>
> --althouth I have  myapp_applicationagencyseer
>
> id   created   agency_id  
>  application_id status
>
> 1 2018-12-10 17:41:14.272684  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
> 7cb60afc-109d-4570-ad24-6cad6b7ddd9a1
> 2 2018-12-11 19:25:58.818000  9e71cff4-443d-4c60-ac2d-9dcca2a9c147
> 7cb60afc-109d-4570-ad24-6cad6b7ddd9a0
>
>
> -- myapp_agency
>
> organization_ptr_idaccreditation   parent
>
> aff44d42-ce81-4c3e-b6e1-056ed9351adb  Null   Null
>
> 9e71cff4-443d-4c60-ac2d-9dcca2a9c147  10АА71 Null   <-- It have 
> Null parent
>
>
>
> Why Query have `INNER JOIN "myapp_agency" U3 ON (U2."organization_ptr_id" 
> = U3."parent_id")` . 
>
>

-- 
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/59d98393-0e96-4fd7-9a73-cfea2c83f447%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A Django Async Roadmap

[Ray Marceau]

James Addison,

 I also currently use `psycogreen.gevent` for postgresql async behaviour.
>

How did you go about using psycogreen.gevent for async postgres?  I tried 
using various tools and was unsuccessful in seeing any performance 
improvements.  I was following the info 
here: 
https://medium.com/@bfirsh/squeezing-every-drop-of-performance-out-of-a-django-app-on-heroku-4b5b1e5a3d44

Have any suggestions/tips?  django blocking while waiting for postgres is a 
huge bottleneck for my app.

Thanks!


How did you go about using psycogreen.gevent for postgresql async 
behavior?  I'm 
On Tuesday, August 21, 2018 at 10:16:03 AM UTC-7, James Addison wrote:
>
> On Monday, June 4, 2018 at 6:18:23 AM UTC-7, Andrew Godwin wrote:
>>
>> For a while now I have been working on potential plans for making Django 
>> async-capable, and I finally have a plan I am reasonably happy with and 
>> which I think we can actually do.
>>
>
> Andrew,
>
> Out of curiosity, how would these kinds of changes interact with gunicorn 
> running with a `gevent` worker? I also currently use `psycogreen.gevent` 
> for postgresql async behaviour.
>
> Thanks,
> James
>

-- 
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/3f676d11-7b2c-41f7-a19f-d34f3b0a1b50%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.