This will hopefully help when getting issue-reports for those that
have not set up dogfooding.
See [Dogfooding Bugsink](https://www.bugsink.com/docs/dogfooding/)
When the CSRF view is rendered, no RequestContext is used. This means the token
used for the logout link on the regular base.html won't work.
> UserWarning: A {% csrf_token %} was used in a template, but the context did not
> provide the value. This is usually caused by not using RequestContext.
In particular:
* Move building of mysqlclient (expensive, mostly unchanging) up
* Move handling of WHEEL_FILE down (always changing for invocations)
The advantages are most clear when running buildx.
This was prompted by discussions on #68, when I tried to explain my
reasoning for the current way things were working (building wheels,
and then copying them over) but I couldn't really justify that, so
I got rid of it instead. (detail: I noticed that psycopg[binary] did
not follow this pattern, which made me question it more broadly)
Fix#56
Looked into this for a while, but I think it was simply an oversight in
the logic-as-programmed; if you're part of a team, you should be able
to just click 'join' on any of that team's projects and be a project-member
See #46
Being a bit more liberal w/ allowing localhost/127.0.0.1 may also
result in proxies that don't pass "Host:" correctly to fail a bit
later; this could be either good or bad; I'm assuming "bad", since
I'd rather fail early and explicitly, but I'm also assuming such
problems will not become that much harder to figure out, so I'm
accepting this.
somewhere, there's a case that such settings need a different level of
authorization; (just because you're the admin of the project doesn't mean you
should be able to do things that affect the system as a whole) but we don't
have such a level ATM.
no need to calculate event_qs_count (which is potentially expensive) if that's
not used in display.
when counting was moved from the template to the view (in 1eea9268a5) it was
made unconditional; here we restore that behavior.
this error has shown up for one of our users; I can't reproduce yet, but I can
make it better:
* log-don't-crash: not worth failing for this (drops the event, and also
rolls back the transaction such that nothing is achieved regarding eviction)
* provide more info on-error (various counts)
NB: I've also changed the < into a <=, and combined it with a check on "loop
not done". I _think_ they are functionally equivalent, and that the new version
is simply more clear as well as slightly more efficient.
In my understanding: the old version simply looped one more time before giving
up (because it was < it needed one more iteration, and because there was no
explicit check on 'loop done' that inefficiency was needed in the old formulation).
I say "I think" because I don't have a test specific to the edge-case.
