qq, we’re trying to run django with its autoreload...
# general
h
qq, we’re trying to run django with its autoreload functionality in pants v2.2 but the way that django performs the autoreload looks like it’s spawning a subprocess and copying the environment. https://github.com/django/django/blob/master/django/utils/autoreload.py#L250-L256 In doing so it is failing saying it can’t load the
django
module. Seems like it’s losing sys.path information. I tried using
--loop
and disabling the django autoreload functionality hoping pants could do that for me but when testing a file change pants wasn’t restarting the run goal. Any ideas?
w
as it mentions, goals are not interruptible in general… but we’re hoping to allow that to be configurable soon
@helpful-lunch-92084: would you mind describing the whole usecase on the ticket? it will help a lot with implementing it in a useful fashion
we’re hoping to tackle it before this summer, but we might be able to bump it up a bit, because it’s not a ton of work
h
sure
so just to be clear, just add a +1 and our use case in the 9462 tkt?
w
that’s right
h
q, if this functionality were added, would it be possible to backport it to pants 2.2? I ask because right now we’re in a tough spot where we still have a bunch of py2 code and we can’t enable the 2020-resolver due to it being horribly slow on py2 and we can’t upgrade to pants 2.4 since i’ve heard it drops support for the pip legacy-resolver.
w
2.2 would be a bit of a stretch, but… maybe 2.3 though?
h
ok
w
i expect that if we were going to extend support for a “pre-resolver removal” version, it would likely be
2.3.x
h
@helpful-lunch-92084 won't be removed till 2.5. 2.4 only changes the default
👍 1
h
ah cool