<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 27 Apr 2019 at 07:57, Marius Gedminas <<a href="mailto:marius@gedmin.as">marius@gedmin.as</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Um, I sent a reply to this on Apr 16. Did it get stuck in some<br>
moderation queue? Are my PGP signatures at fault?<br>
<br>
On Fri, Apr 26, 2019 at 09:37:38PM +0100, Shaheed Haque wrote:<br>
> Apologies for the bump, but I'm really stuck for what to try next.<br>
> <br>
> P.S. I did also email the Django list, but that was [1]similarly quiet.<br>
> <br>
> <br>
> On Tue, 16 Apr 2019 at 12:03, Shaheed Haque <[2]<a href="mailto:shaheedhaque@gmail.com" target="_blank">shaheedhaque@gmail.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I'm trying to get coverage.py to generate results for code running<br>
> under the Django server [1]. I expected that the initial difficulty<br>
> would be with having the server exit in a manner which allowed the<br>
> end-of-run coverage logic to get a chance to run. I hacked a solution<br>
> to that [2], and I can now say<br>
> <br>
> $ coverage -p manage.py runserver ...<br>
<br>
TL;DR is try passing --noreload to runserver.<br>
<br>
> Though I could be mistaken, AFAIK, Django does not use any of the<br>
> constructs which are known sources of incompatibility. <br>
<br>
It does: the Django autoreloader spawns a subprocess to run the actual<br>
view code (that gets killed and restarted every time the autoreloader<br>
detects source code changes).<br></blockquote><div><br></div><div>Wow. Thanks for the hint, I'll give it a try!<br></div><div> </div><div>Shaheed<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Marius Gedminas<br>
-- <br>
I doubt, therefore I might be.<br>
</blockquote></div></div>