Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 14 19:31
    CaselIT commented #1828
  • Sep 14 19:13
    adriangb commented #1828
  • Sep 14 18:13
    vytas7 commented #1828
  • Sep 14 18:12
    vytas7 commented #1828
  • Sep 14 17:58
    owais commented #1828
  • Sep 14 17:56
    owais commented #1828
  • Sep 14 17:56
    owais commented #1828
  • Sep 14 17:35
    adriangb commented #1828
  • Sep 14 17:00
    vytas7 commented #1828
  • Sep 14 09:39
    owais commented #1828
  • Sep 14 09:32
    owais commented #1828
  • Sep 14 09:31
    owais commented #1828
  • Sep 03 22:07
    adriangb commented #1908
  • Sep 03 21:59
    CaselIT commented #1908
  • Sep 03 21:59
    CaselIT commented #1908
  • Sep 03 21:52
    CaselIT commented #1908
  • Sep 03 21:52
    CaselIT commented #1908
  • Sep 03 21:52
    CaselIT commented #1908
  • Sep 03 21:42
    adriangb commented #1908
  • Sep 03 21:41
    adriangb commented #1908
Federico Caselli
@CaselIT
asyncio is so fast that's broken sometimes :)
Vytautas Liuolia
@vytas7
Too speedy
Federico Caselli
@CaselIT
should we take over this one? falconry/falcon#1928
Vytautas Liuolia
@vytas7
I 've just pinged the author very recently, maybe we could wait for a couple of days more, and then take over in the absence of answer?
Federico Caselli
@CaselIT
makes sense
Vytautas Liuolia
@vytas7
@dimucciojonathan I've tested in Docker on Ubuntu 20.04, and after some fiddling it did work.
You could probably just try eval "$(pyenv init -)" in your shell to initialize/activate it temporarily.
Vytautas Liuolia
@vytas7
@dimucciojonathan The task you volunteered to work on is ASGI-only, so it's probably enough you just use one of 3.7, 3.8 or 3.9. Check tox -e py38 and black, and should you miss anything else, it will be caught by the CI in the worst case.
You could save some roundtrip time by checking coverage locally though, but that does require a combo with 3.5.
dimjon
@dimucciojonathan
Thanks for the responses! I made the simple mistake of not being in the activated virtualenv.. haha. The line pyenv shell 3.8.0 3.5.8 worked once I was activated. After this task I will set up a venv similar to what you both are running.
Kurt Griffiths
@kgriffs
@vytas7 were you already working on a recipe for embedding workers in a falcon app? (See also falconry/user)
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
Vytautas Liuolia
@vytas7
@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.)
Vytautas Liuolia
@vytas7
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.)
Kurt Griffiths
@kgriffs
good catch!
Vytautas Liuolia
@vytas7
It's useful to try reading the docs from the user perspective, not something I do too often. :imp:
Kurt Griffiths
@kgriffs
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.
Vytautas Liuolia
@vytas7
Well, we do have the said schedule() method for ASGI, but yes, asyncio sort of lends itself well to spawning a task, whereas on WSGI there is no universal method (a worker thread, but what if one is using gevent? is monkeypatching in effect or not?).
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
Kurt Griffiths
@kgriffs
lol.
You should just write a book and get it over with.
#fame #fortune #skills #imaginaryinternetbonuspoints
Vytautas Liuolia
@vytas7
More srsly speaking, I'll try to finish the recipe I had in progress for a long while now.
:shipit:
Kurt Griffiths
@kgriffs
I'm not one to talk; I've had falcon TODOs staring at me for quite a while. Those beady little eyes are unnerving...
Vytautas Liuolia
@vytas7
Another related area where I believe we definitely need to do more is devops/deployment recipes, maybe with more concrete examples (already tracked in many issues).
The NGINX+uWSGI guide @nZac has written is still the only one we have.
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.
Federico Caselli
@CaselIT
I was planning some further work on the router. Should I start as a new pr as a follow up of falconry/falcon#1945 ?
Vytautas Liuolia
@vytas7
Very weird that our coverage stays at the 75% badge, despite me rerunning the latest master action... Could it have been picked from a Draft PR by a community contributor, and why?
Vytautas Liuolia
@vytas7
@dimucciojonathan I've commented out your prototype for a while, weird as it sounds...
(Maybe it's better if you open a PR from a branch, not from master on your fork.)
dimjon
@dimucciojonathan
@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.
Vytautas Liuolia
@vytas7
Thanks a lot, I'll take a look!
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).
Kurt Griffiths
@kgriffs
I added that lambda/serverless issue as a recipe suggestion on the roadmap under Docs: falconry/falcon#1894
dimjon
@dimucciojonathan
Yea I never knew that could happen, but no problem since a branch is how a PR should be done anyways
Vytautas Liuolia
@vytas7
Hm, found an undocumented breaking change for 3.0 :grimacing:
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.
Federico Caselli
@CaselIT
I think we could just correct the chanelog if the new behaviour doesn't cause issues
Vytautas Liuolia
@vytas7
It did cause a minor issue for me in a real code base, where a part of the tested code was a generic/non-Falcon WSGI app which was expecting REMOTE_ADDR to be present. Probably a true edge case and easy to work around, but still.
Vytautas Liuolia
@vytas7

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_addr

But OTOH we cannot edit the past... so maybe we could add a note as part of 3.0.2?

Federico Caselli
@CaselIT
Fine for me!
Kurt Griffiths
@kgriffs
Nice catch, I must have forgotten to add a breaking change note.