You could probably just try
eval "$(pyenv init -)" in your shell to initialize/activate it temporarily.
You could save some roundtrip time by checking coverage locally though, but that does require a combo with 3.5.
Seems like this is a common question/topic
Two flavors: (1) where a request to the app triggers a background task, and (2) where the app acts as a consumer of a message bus
@kgriffs yes and no, I haven't started working on that, but I had a recipe in my mind. I didn't think of external providers, I was thinking to write a recipe similar to that Gist you saved, plus mention/illustrate the use of multiprocessing and discuss the common pitfalls wrt forking, initialization and cleanup; and when it comes to ASGI, I was going to mention at least
resp.schedule().
(Because multiprocessing was another sticky topic that led to multiple issues being filed and raised on Gitter.)
Oh, and it seems that text formatting is slightly broken by the end of
resp.schedule()'s paragraph :grimacing:
Parameters
callback (object) – An async coroutine function. The callback will be
without arguments. (invoked) –
(I can clean up in my next docs PR.)
wrt workers/tasks, as you point out, there are many subtleties to consider on this topic and it would be good to give people some guidance. I'm starting to wonder if there are additional affordances we can add into the framework, or provide a common integration point for this sort thing, but I'm not sure how much we can do without becoming too opinionated/bloated.
Maybe we can start off with a recipe. And we need more contributors to the Recipes section :slight_smile:
Because IIRC all current recipes except one are written by the same author
vytas7 @vytas7 bad poker face
You should just write a book and get it over with.
#fame #fortune #skills #imaginaryinternetbonuspoints
:shipit:
Although theoretically you can use a Falcon app callable with any app server, and refer to its docs, but in practice people are too lazy to search nowadays.
Moreover, as we're perf oriented, there might be specific setups to document on how to max out throughput.
Moreover, as we're perf oriented, there might be specific setups to document on how to max out throughput.
I was planning some further work on the router. Should I start as a new pr as a follow up of falconry/falcon#1945 ?
(Maybe it's better if you open a PR from a branch, not from
master on your fork.)
@vytas7 sounds good! I created a new PR from a separate branch, feel free to let me know what else I can do for this task. A few of the test cases failed. I'm not sure if it's from an incorrect implementation, or the fact that I changed the code which triggered the assertions.
And it's very lame that a Draft PR can affect our front page badge, I didn't know that. But it's none of your fault, just an awkward bug on codecov's side (or our integration).
I added that lambda/serverless issue as a recipe suggestion on the roadmap under Docs: falconry/falcon#1894
It seems that
falcon.testing.create_environ() will no longer add REMOTE_ADDR to the created environ, although the changelog only mentions the changed interpretation of the remote_addr property: Breaking Changes.
But yeah, it does look like the change was intentional, and it does make sense:
# NOTE(kgriffs): It has been observed that WSGI servers do not always
# set the REMOTE_ADDR variable, so we don't always set it either, to
# ensure the framework/app handles that case correctly.
if remote_addr:
env['REMOTE_ADDR'] = remote_addrBut OTOH we cannot edit the past... so maybe we could add a note as part of 3.0.2?