[Django] #29456: Django 1.11 same filter_list get redisplayed in different model admin page

[Django]

#29456: Django 1.11 same filter_list get redisplayed in different model admin 
page
-+-
   Reporter:  grpoundblue|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.11
   Severity:  Normal |   Keywords:  list_filter
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm getting this behavior after updating Django from 1.8 to 1.11.

 {{{

 modelAAdmin(admin.ModelAdmin)
  list_filter = ('filter_a',)

 modelBAdmin(admin.ModelAdmin)
  list_filter = ('filter_b',)
 }}}

 If I navigate to modelA admin page first and than move to modelB admin
 page the filters defined in modelA are displayed instead of the modelB's
 one.
 Making a selection on the wrongly displayed filter appends ** ?e=1** and
 no error displayed.
 This also happen if there is more than two model admin classes.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/054.b768c521c45b54aae792eba92973899b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27147: Add support for defining bounds in postgres range fields

[Django]

#27147: Add support for defining bounds in postgres range fields
-+-
 Reporter:  Kirill Stepanov  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgres range   | Triage Stage:  Accepted
  bounds |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matthew Schinckel):

 Oh, I did this at the form field level.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.bdb96ae62e420b9382e926f9fae74276%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27147: Add support for defining bounds in postgres range fields

[Django]

#27147: Add support for defining bounds in postgres range fields
-+-
 Reporter:  Kirill Stepanov  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  postgres range   | Triage Stage:  Accepted
  bounds |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Matthew Schinckel):

 There's two parts: ensuring that the user-entered-data is upper-bounds-
 inclusive, and ensuring that the saved data is presented back to the user
 as upper-bounds-inclusive.

 The first part of this is trivial - just have a bounds value of '[]'
 passed in to the constructor. In my case, I have an InclusiveRangeMixin
 that does this in compress.

 The second part is less clear - because in the case of distinct range
 types there is a "unit value" that needs to be removed from the upper
 bounds, but in the case of continuous ranges, this is not possible (but in
 that case, postgres will not have normalised it, so it's all good).

 Anyway, code speaks louder than words here, so here's how I've approached
 this in the past:


 {{{
 class InclusiveRangeMixin(object):
 _unit_value = None

 def compress(self, values):
 range_value = super(InclusiveRangeMixin, self).compress(values)
 if range_value:
 return self.range_type(range_value.lower, range_value.upper,
 bounds='[]')

 def prepare_value(self, value):
 value = super(InclusiveRangeMixin, self).prepare_value(value)
 # We need to clean both fields.
 value = [field.clean(val) for field, val in zip(self.fields,
 value)]
 if value[1] is not None:
 value[1] = value[1] - self._unit_value
 return value


 class InclusiveDateRangeField(InclusiveRangeMixin, DateRangeField):
 _unit_value = datetime.timedelta(1)


 class InclusiveIntegerRangeField(InclusiveRangeMixin, IntegerRangeField):
 _unit_value = 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e1fb71f13201b31d5ae7a5637621f4b1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28862: Removing a field from index_together/unique_together and from the model generates a migration that crashes

[Django]

#28862: Removing a field from index_together/unique_together and from the model
generates a migration that crashes
---+
 Reporter:  Artem Maslovskiy   |Owner:  Jeff
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  models migrations  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Jeff):

 Ramiro Morales pointed out I am working on another duplicate #29123. I'll
 take ownership of this as well.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.7bfe36c346306e90b0f3ee2e621d0925%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered migration operations if the field is in unique_together

[Django]

#29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered
migration operations if the field is in unique_together
+
 Reporter:  Ed Morley   |Owner:  Jeff
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 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
+

Comment (by Jeff):

 Thanks for the tip, I do believe it to be the same issue.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.e07ff956c5d15fee3b587df2fbe8d8b6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28862: Removing a field from index_together/unique_together and from the model generates a migration that crashes

[Django]

#28862: Removing a field from index_together/unique_together and from the model
generates a migration that crashes
---+
 Reporter:  Artem Maslovskiy   |Owner:  Jeff
 Type:  Bug|   Status:  assigned
Component:  Migrations |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords:  models migrations  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Jeff):

 * owner:  (none) => Jeff
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.ba1f6bf06b3eccf75a0d518302409070%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28892: Fixed header height in the admin site may break custom layouts

[Django]

#28892: Fixed header height in the admin site may break custom layouts
---+--
 Reporter:  Claude Paroz   |Owner:  Sara Heins
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.9
 Severity:  Normal |   Resolution:  fixed
 Keywords:  css| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5008d59a2a8b9df09737fc05c9e343146a348a90" 5008d59a]:
 {{{
 #!CommitTicketReference repository=""
 revision="5008d59a2a8b9df09737fc05c9e343146a348a90"
 Fixed #28892 -- Allowed admin navbar height to expand if needed.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.ff536c3a408d0d02fe5ef37aa5340b5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28748: Named groups in choices are not properly validated

[Django]

#28748: Named groups in choices are not properly validated
-+-
 Reporter:  Scott Stevens|Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  choices  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4ca64f2bd52dea691e33473dc97f8ee9e2a1130d" 4ca64f2b]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ca64f2bd52dea691e33473dc97f8ee9e2a1130d"
 [2.1.x] Refs #28748 -- Reallowed lazy model field choices.

 Regression in 3aa9ab39cce6b2a27d6334ad0148c8f37b6f5986.

 Backport of c03e41712b2274f524d32bc2aef455ed82c9e3b4 from master
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.41178a088ec4a35e8334cc400de84c3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28748: Named groups in choices are not properly validated

[Django]

#28748: Named groups in choices are not properly validated
-+-
 Reporter:  Scott Stevens|Owner:  François
 |  Freitag
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  choices  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"c03e41712b2274f524d32bc2aef455ed82c9e3b4" c03e4171]:
 {{{
 #!CommitTicketReference repository=""
 revision="c03e41712b2274f524d32bc2aef455ed82c9e3b4"
 Refs #28748 -- Reallowed lazy model field choices.

 Regression in 3aa9ab39cce6b2a27d6334ad0148c8f37b6f5986.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e93007875cbebdeef0c0728d790d4de6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered migration operations if the field is in unique_together

[Django]

#29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered
migration operations if the field is in unique_together
+
 Reporter:  Ed Morley   |Owner:  Jeff
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 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
+

Comment (by Ramiro Morales):

 Looks suspiciously similar or at least related to #28862.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.484c839d8d532f57bc0c7064df2f53ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29385: Make ModelDetailView show model properties

[Django]

#29385: Make ModelDetailView show model properties
-+-
 Reporter:  Bostjan Kaluza   |Owner:
 Type:   |  humbertotm
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  2.0
 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 Claude Paroz):

 * needs_better_patch:  1 => 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.47929da600293d37f90de6124b1ada3f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered migration operations if the field is in unique_together

[Django]

#29123: Changing an IntegerField to a ForeignKey generates incorrectly ordered
migration operations if the field is in unique_together
+
 Reporter:  Ed Morley   |Owner:  Jeff
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  master
 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
+

Comment (by Jeff):

 I have tracked down the issue to the migration optimization. Debugging now
 to determine how to ensure a field cannot be removed while it is a part of
 a `unique_together` constraint.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.3847ff34729139d1b50af38c0d131d4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29416: Undesired subquery added to the GROUP BY clause

[Django]

#29416: Undesired subquery added to the GROUP BY clause
-+-
 Reporter:  Antoine Pinsard  |Owner:  felixxm
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  groupby, subquery| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 MySQL documentation for reference.

 https://dev.mysql.com/doc/refman/5.7/en/sql-
 mode.html#sqlmode_only_full_group_by

 Tim, is the only MySQL 5.7 failing against this patch?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d5923d348d5e57fa4784568c2b4263c2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29385: Make ModelDetailView show model properties

[Django]

#29385: Make ModelDetailView show model properties
-+-
 Reporter:  Bostjan Kaluza   |Owner:
 Type:   |  humbertotm
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by humbertotm):

 Added documentation to PR. Let me know what you think, and how this can be
 improved.
 Thanks!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.63b5e30b0e475a409d1a587663b1ee7e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29385: Make ModelDetailView show model properties

[Django]

#29385: Make ModelDetailView show model properties
-+-
 Reporter:  Bostjan Kaluza   |Owner:
 Type:   |  humbertotm
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admindocs|  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by humbertotm):

 Replying to [comment:7 Claude Paroz]:
 > For the docs, something like `with all the fields and methods available
 on it` -> `with all the fields, properties and methods available on it`,
 with a `versionchanged` section stating that showing model properties has
 been added.

 Great! I'm on it.
 Thanks!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9ac823a4f13e0f65e2ca3b333ea28e00%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29416: Undesired subquery added to the GROUP BY clause

[Django]

#29416: Undesired subquery added to the GROUP BY clause
-+-
 Reporter:  Antoine Pinsard  |Owner:  felixxm
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  groupby, subquery| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  closed => new
 * has_patch:  1 => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Accepted


Comment:

 This broke a MySQL GIS test on MySQL 5.7:
 {{{
 gis_tests.geoapp.test_expressions.GeoExpressionsTests.test_multiple_annotation

 Expression #2 of SELECT list is not in GROUP BY clause and contains
 nonaggregated column 'test_django.geoapp_multifields.point' which is not
 functionally dependent on columns in GROUP BY clause; this is incompatible
 with sql_mode=only_full_group_by")
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.b6d1c9906d5293474a22cf7be93568b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28044: Different logic in createsuperuser command between interactive and non-interactive mode

[Django]

#28044: Different logic in createsuperuser command between interactive and non-
interactive mode
-+-
 Reporter:  Sławek Ehlert|Owner:  DoHyun
 Type:   |  Kim
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  createsuperuser  | Triage Stage:  Accepted
  management command |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f1f4aeb22e7bc9b504f69f7cb111ac9bdedb5f1e" f1f4aeb2]:
 {{{
 #!CommitTicketReference repository=""
 revision="f1f4aeb22e7bc9b504f69f7cb111ac9bdedb5f1e"
 Fixed #28044 -- Unified the logic for createsuperuser's interactive and
 --noinput modes.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.073c8213a16ea53c3af24b419b594cef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28905: Overhaul extra_requires to include more optional dependencies

[Django]

#28905: Overhaul extra_requires to include more optional dependencies
-+-
 Reporter:  Jaap Roes|Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Packaging|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  setup optional   | Triage Stage:  Accepted
  dependencies packages  |
  requirements   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Jaap Roes):

 Yes please claim it, it would be really helpful to, for example, identify
 pieces of documentation that should be updated when this lands.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.f58fa11f69321473e53cabe223b14fbb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.