#32128: Issue with asgiref dependency installing Django 3.1.x
-------------------------------------+-------------------------------------
Reporter: Carlton Gibson | Owner: nobody
Type: | Status: new
Cleanup/optimization |
Component: Core (Other) | Version: 3.1
Severity: Release blocker | 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 Mariusz Felisiak):
* type: Bug => Cleanup/optimization
Comment:
Replying to [ticket:32128 Carlton Gibson]:
> It looks like we've misspecified the `asgiref` dependency in Django
3.1.x.
>
> Specifically, I think we wanted ''latest asgiref that wasn't 4 (i.e. a
break)'' but installing we're not picking up the latest asgiref 3.3, which
we want (because it makes the `thread_sensitive` parameter default
`True`).
>
I don't agree, we did this on purpose to avoid any breaking changes in
supported versions of `asgiref`, from IRC (June 2020):
{{{
<andrewgodwin> Any opinions on changing the Django asgiref dependency to
`~=3.2,>=3.2.8`? I'd like to allow a 4.0 release to possibly exist with
different APIs, and 3.2.8 has an important contextvars fix in it.
<felixx> andrewgodwin: I'm not sure if we need to add >= 3.2.8
<andrewgodwin> felixx: Well, if people already have an environment with
3.2.7 installed and Django 3.0, I sort of want to force an upgrade there
<felixx> we officially always recommend the newest version
<felixx> we don't have an asgiref version pinned in Django 3.1
<felixx> we can always pin it before the rc1
<andrewgodwin> Yeah, my main concern is moving from `>=3.2` to `~=3.2`
<andrewgodwin> It sort of blocks us from making a breaking change in
asgiref for 3 years
<andrewgodwin> The Sentry folks would say it's important enough (3.2.7
doesn't handle contextvars correctly)
<felixx> in Django 3.0 we have ~3.2
<andrewgodwin> Yes, I saw that
<untitaker> hi I just got pinged by keyword. I'm the one from Sentry
making that claim. I don't really know anything about the tradeoff you are
considering, but my concern is that when somebody upgrades django without
upgrading asgiref, they will see their
before_request/after_request/got_request_exception being executed with the
wrong context. Whether that's within scope of the API contract (and
whether that is a regression)
<untitaker> is up to you.
<felixx> IMO we shouldn't change it
<felixx> we can discuss what to do with Django 3.1
<andrewgodwin> Yeah I care about Django 3.1, not 3.0
<andrewgodwin> 3.0 doesn't have proper async views - as untitaker says,
that will be much more confusing in 3.1 when people start using them
<felixx> I will discuss this tomorrow with Carlton, I asked him about
pinning asgiref version for Django 3.1 sometime ago
<andrewgodwin> OK!
}}}
As far as I'm aware `asgiref 3.3` is a breaking release because it changed
the default value of `thread_sensitive`. We can of course change the
requirements, but IMO that's a new feature (or cleanup) but not a bug. It
will probably require some docs changes.
--
Ticket URL: <https://code.djangoproject.com/ticket/32128#comment:1>
Django <https://code.djangoproject.com/>
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.8217838ffcc2f03aecfbba24699f61c6%40djangoproject.com.
