Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
 Reporter:  Hugo Cachitas|Owner:  Hugo
 |  Cachitas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"f83214a3e15ccadc9e2370dd157ed19bcdb07e2c" f83214a3]:
 {{{
 #!CommitTicketReference repository=""
 revision="f83214a3e15ccadc9e2370dd157ed19bcdb07e2c"
 Refs #32594 -- Added Signal.disconnect() test with a model class.

 Co-authored-by: Mariusz Felisiak 
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.ebfd3139ec41df5bdf9246976a87dd72%40djangoproject.com.

Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
---+-
 Reporter:  Hugo Cachitas  |Owner:  Hugo Cachitas
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords:  signals| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * component:  Database layer (models, ORM) => Documentation
 * needs_docs:  0 => 1


Comment:

 I think we should document the current behavior.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.f977d85ee70e54fc382d6cb0afc7d3ff%40djangoproject.com.

Re: [Django] #32204: Quick Filter for the Admin Sidebar

[Django]

#32204: Quick Filter for the Admin Sidebar
-+-
 Reporter:  Maxim Milovanov  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.25ba69de256780306ba6c475fc0f853c%40djangoproject.com.

Re: [Django] #32316: Access __file__ lazily rather than at module level

[Django]

#32316: Access __file__ lazily rather than at module level
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  freezers | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7248afe12f40361870388ecdd7e0038eb0d58e47" 7248afe1]:
 {{{
 #!CommitTicketReference repository=""
 revision="7248afe12f40361870388ecdd7e0038eb0d58e47"
 Refs #32105 -- Moved ExceptionReporter template paths to properties.

 Refs #32316.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.047237c67a21ffe2f3699f019a3fc94f%40djangoproject.com.

Re: [Django] #32105: Allow overriding technical 500 page templates

[Django]

#32105: Allow overriding technical 500 page templates
-+-
 Reporter:  Aarni Koskela|Owner:  Aarni
 |  Koskela
 Type:  New feature  |   Status:  closed
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7248afe12f40361870388ecdd7e0038eb0d58e47" 7248afe1]:
 {{{
 #!CommitTicketReference repository=""
 revision="7248afe12f40361870388ecdd7e0038eb0d58e47"
 Refs #32105 -- Moved ExceptionReporter template paths to properties.

 Refs #32316.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.5dc758826f5f8ef0eed7f372bc5b2359%40djangoproject.com.

Re: [Django] #32316: Access __file__ lazily rather than at module level

[Django]

#32316: Access __file__ lazily rather than at module level
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  freezers | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"a118564ae167fa80c2628b1d22292794af4c0341" a118564a]:
 {{{
 #!CommitTicketReference repository=""
 revision="a118564ae167fa80c2628b1d22292794af4c0341"
 [3.2.x] Refs #32105 -- Moved ExceptionReporter template paths to
 properties.

 Refs #32316.

 Backport of 7248afe12f40361870388ecdd7e0038eb0d58e47 from main
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.ff732c83350bdfc73a61731756bb454f%40djangoproject.com.

Re: [Django] #32105: Allow overriding technical 500 page templates

[Django]

#32105: Allow overriding technical 500 page templates
-+-
 Reporter:  Aarni Koskela|Owner:  Aarni
 |  Koskela
 Type:  New feature  |   Status:  closed
Component:  Error reporting  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"a118564ae167fa80c2628b1d22292794af4c0341" a118564a]:
 {{{
 #!CommitTicketReference repository=""
 revision="a118564ae167fa80c2628b1d22292794af4c0341"
 [3.2.x] Refs #32105 -- Moved ExceptionReporter template paths to
 properties.

 Refs #32316.

 Backport of 7248afe12f40361870388ecdd7e0038eb0d58e47 from main
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.59d2bc7a6203e30c8b8203968a5cef11%40djangoproject.com.

Re: [Django] #32204: Quick Filter for the Admin Sidebar

[Django]

#32204: Quick Filter for the Admin Sidebar
-+-
 Reporter:  Maxim Milovanov  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"d915dd1c5809d7c2bb3679751cd5277571dcd9f7" d915dd1]:
 {{{
 #!CommitTicketReference repository=""
 revision="d915dd1c5809d7c2bb3679751cd5277571dcd9f7"
 Fixed #32204 -- Added quick filter to admin's navigation sidebar.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.94992529ddd6d297f102b3fa6d0a4af6%40djangoproject.com.

Re: [Django] #31885: Update SMTP Email Backend to use an SSLContext.

[Django]

#31885: Update SMTP Email Backend to use an SSLContext.
---+-
 Reporter:  Luis Saavedra  |Owner:  Luis Saavedra
 Type:  Bug|   Status:  assigned
Component:  Core (Mail)|  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords:  SSL| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+-

Comment (by Carlton Gibson):

 So
 [https://github.com/django/django/pull/13305#pullrequestreview-625047316
 conclusion on the PR] is that we should add the option to accept the
 parameters for an SSLContext on EmailBackend but **not** add them as
 settings. (The default is to use the system CA certs which is what most
 people want/need.)

 We will then recommend subclassing in the docs for more control.

 At the same time we should deprecate EMAIL_SSL_CERTFILE and
 EMAIL_SSL_KEYFILE for the same reasons.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.6cc0b7d11887b9802bbb7448286e2213%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e1a57b81135190228b8a44380e19f726%40djangoproject.com.

Re: [Django] #30416: Runserver's reloading mechanism should restore terminal state completely

[Django]

#30416: Runserver's reloading mechanism should restore terminal state completely
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel
 |  Hahler
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.2
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_tests:  0 => 1


Comment:

 I've left
 [https://github.com/django/django/pull/11291#pullrequestreview-625215987
 comments on PR] — ultimately I'm not sure we need to resolve this
 ourselves…

 Maybe offering a way to pause the auto-reloader if you're in a debugger
 (as per comment:5 — but not necessarily with the lock approach in linked
 PR), but even then, I'm not sure we're committed to the auto-reloader
 working flawlessly if you save file changes whilst working in the
 debugger.

 Possibly the suggested patch is a marginal improvement, but there are no
 tests at all. (Indeed some coverage is removed.) I'm not sure if we can
 come up with decent tests to make sure we don't introduce regressions.
 (It's on that untestable edge.) If we do merge this I think we need to ask
 regular contributors to try and break it with their debugging setup just
 to be sure we didn't break something else unexpectedly.

 Current status ≈-0

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ed16d45a386af5c5bc841a460cf01244%40djangoproject.com.

Re: [Django] #31169: Allow parallel test runner to work with Windows/macOS `spawn` process start method.

[Django]

#31169: Allow parallel test runner to work with Windows/macOS `spawn` process 
start
method.
-+-
 Reporter:  Brandon Navra|Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ahmad A. Hussein):

 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.db9b54f09c29d78cb83ef0749ca7cf90%40djangoproject.com.

Re: [Django] #32608: Collation test fails on PostgreSQL on Windows due to missing locale

[Django]

#32608: Collation test fails on PostgreSQL on Windows due to missing locale
-+-
 Reporter:  Ahmad A. Hussein |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Thanks for this report, however I don't think you've explained the issue
 in enough detail to confirm a bug in schema test. It works for me on
 PostgreSQL 12 and 13. Please reopen this ticket if you can provide more
 details, especially why Django is at fault.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8ca989881697127ac23095fa79d7efce%40djangoproject.com.

Re: [Django] #32607: DateTimeField in django administration bug

[Django]

#32607: DateTimeField in django administration bug
---+--
 Reporter:  mypseudo   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by mypseudo:

Old description:

> In django administration when wanting to save a DateTimeField, it raises
> a ValidationError "This field is mandatory" if we only provide a date and
> no time.

New description:

 In django administration when wanting to save a DateTimeField, it raises a
 ValidationError "This field is mandatory" if we only provide a date and no
 time.

 Create a Model with a DateTimeField, register it on django.contrib.admin,
 makemigrations and migrate, then go to django administration in browser
 and try saving it without providing in the time : it raises a Validation
 error.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.196a8906a1ae1115ff2ccd80cef42c67%40djangoproject.com.

Re: [Django] #32607: DateTimeField in django administration bug

[Django]

#32607: DateTimeField in django administration bug
---+--
 Reporter:  mypseudo   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by mypseudo):

 * Attachment "toto.png" added.

 Screenshot of the bug in browser after having clicked "Save" button with
 the same content

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.df27e2cd8b83345be2fdd4c35b5a97c2%40djangoproject.com.

Re: [Django] #32607: DateTimeField in django administration bug

[Django]

#32607: DateTimeField in django administration bug
---+--
 Reporter:  mypseudo   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is working as intended. If you want to make the time optional, you
 can customize the field.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bc2068982e57028cd2d3e519bac955d8%40djangoproject.com.

[Django] #32608: Collation test fails on PostgreSQL on Windows due to missing locale

[Django]

#32608: Collation test fails on PostgreSQL on Windows due to missing locale
+
   Reporter:  Ahmad A. Hussein  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 
https://github.com/django/django/blob/f83214a3e15ccadc9e2370dd157ed19bcdb07e2c/tests/schema/tests.py#L4028

 This test fails on Windows with the specified locale. Changing ```locale =
 'und-u-ks-level2'``` to ```locale = '@colStrength=secondary'``` fixes this
 but I'm not sure why. I believe the locale used is
 [https://www.postgresql.org/message-id/43f9b6b6-6fae-47bb-8f4d-
 8e84af354...@manitou-mail.org/ missing on earlier Windows PostgreSQL
 installations].

 Is this a bug in the code or a failure specific to my installation?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.6bc193e7744779a46e3cb6a0b96d82df%40djangoproject.com.

[Django] #32607: DateTimeField in django administration bug

[Django]

#32607: DateTimeField in django administration bug
-+
   Reporter:  mypseudo   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In django administration when wanting to save a DateTimeField, it raises a
 ValidationError "This field is mandatory" if we only provide a date and no
 time.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.750cd6e11e24f38af687e2ae92e0ebfc%40djangoproject.com.

Re: [Django] #32606: Allow rich configuration of Selenium tests

[Django]

#32606: Allow rich configuration of Selenium tests
---+--
 Reporter:  Dominik George |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Tim Graham):

 Can you think of a suitable alternative to passing complex data structures
 on the command line? That seems a little verbose and tricky with issues
 like character escaping. Something like
 `--selenium={\"foo\":[{\"bar\":\"baz\"}]}` doesn't look so nice to me.
 Maybe reading configurations from a file?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.f04d7b4b623b17a33597cbababb43bc6%40djangoproject.com.

[Django] #32609: runtests.py setup should use DiscoverRunner's test label logic

[Django]

#32609: runtests.py setup should use DiscoverRunner's test label logic
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  dev
  framework  |   Keywords:
   Severity:  Normal |  DiscoverRunner,runtests
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I noticed that `runtests.py` does its own rudimentary "parsing" of the
 provided test labels here:
 
https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/tests/runtests.py#L128-L132

 However, it would be better if it used the same logic as
 `DiscoverRunner.build_suite()`:
 
https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/django/test/runner.py#L612

 There are a few reasons for this. First, it would let `runtests` take into
 account the test tags when determining which app modules apply. Second, it
 would centralize the test label logic, which should simplify maintenance.
 (For example, I was previously unaware of this code path, which explains
 why some things mysteriously weren't working before.) Third, it might even
 permit test labels to be directory paths when used with `runtests.py`, as
 a free side effect. (Currently, directory paths don't seem to work with
 `runtests.py`, I believe for this reason.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.a67a7090b012d8d9fdf50d9f97985e85%40djangoproject.com.

Re: [Django] #32609: runtests.py setup should use DiscoverRunner's test label logic

[Django]

#32609: runtests.py setup should use DiscoverRunner's test label logic
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,runtests|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.7354827b3ea73ed355dbcfc7619d0c9b%40djangoproject.com.

Re: [Django] #32609: runtests.py setup should use DiscoverRunner's test label logic

[Django]

#32609: runtests.py setup should use DiscoverRunner's test label logic
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  DiscoverRunner,runtests|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Chris Jerdonek:

Old description:

> I noticed that `runtests.py` does its own rudimentary "parsing" of the
> provided test labels here:
> https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/tests/runtests.py#L128-L132
>
> However, it would be better if it used the same logic as
> `DiscoverRunner.build_suite()`:
> https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/django/test/runner.py#L612
>
> There are a few reasons for this. First, it would let `runtests` take
> into account the test tags when determining which app modules apply.
> Second, it would centralize the test label logic, which should simplify
> maintenance. (For example, I was previously unaware of this code path,
> which explains why some things mysteriously weren't working before.)
> Third, it might even permit test labels to be directory paths when used
> with `runtests.py`, as a free side effect. (Currently, directory paths
> don't seem to work with `runtests.py`, I believe for this reason.)

New description:

 I noticed that `runtests.py` does its own rudimentary "parsing" of the
 provided test labels here:
 
https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/tests/runtests.py#L128-L132

 However, it would be better if it used the same logic as
 `DiscoverRunner.build_suite()`:
 
https://github.com/django/django/blob/548dce50cf548e777a0c34b5485a146a0606ae73/django/test/runner.py#L612

 There are a few reasons for this. First, it would let `runtests` take into
 account the test tags when determining which app modules apply. Second, it
 would centralize the test label logic, which should simplify maintenance.
 (For example, I was previously unaware of this code path, which explains
 why some things mysteriously weren't working before.) Third, it might even
 permit test labels to be directory paths when used with `runtests.py`, as
 a free side effect. (Currently, directory paths don't seem to work with
 `runtests.py`, I believe for this reason.) A fourth is that `runtests.py`
 will fail faster if a bad test label is passed.

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.75921c3a4d8c696cddd028c443f8b4b6%40djangoproject.com.