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.
these were development-tools in the 'cornless' disposable web-server style;
not using them now, and if I ever need them back I'll dig them out of the git history.
see https://www.bugsink.com/blog/disposable-web-servers/
It happens with some regularity that people notice the "DEBUG" setting
and try to run with DEBUG=True. Although this is not documented nor recommended
you can't really blame 'm, and it would probably help them debug their issues.
Pre-this-commit that was not possible, because the debug toolbar is usually not
installed (and on e.g. on Docker this is very annoying to do).
