search

yohanboniface / pytest-falcon

Pytest helpers for testing Falcon applications
16 stars 6 forks source link

Makes `fake_request` honor bytes in Python 3 #10

Closed brianbruggeman closed 6 years ago

brianbruggeman commented 7 years ago
brianbruggeman commented 7 years ago

This should be good to go. Note I also added sort of a separate review for Pull Request #11. However, this PR now includes those changes. More or less the changes are all related to how this package is tested both on Travis-CI and locally. The old mechanism ($ pytest) is still viable. But the new mechanism ($ tox) is more comprehensive.

yohanboniface commented 6 years ago

Sorry for my late answer: the PR moved from a simple one line change to a 11 files change, thus it switched from my "easy review" list to my normal todo list, which is much more busy.

The included PR (#11) has nice suggestions, but also some more questionable: adding tox in the workflow (I usually consider a workflow to be better with less tools) or running the CI with non released Python versions (each run takes time, and is using freely Travis resources, so I'd say let's be fair).

That said, to be honest, I'm investing less and less time in Falcon (switching my projects to Roll where I need high speed). So I'd see two options:

Tell me! :)

brianbruggeman commented 6 years ago

Hey - thanks for the feedback.

It's one of those catch 22s, right? Don't change the open source repo too much or it may break something in the ecosystem. Alternatively, not enough change means that the project stagnates and becomes less and less useful over time.

My roots are in embedded flight controls software for military aircraft, where not being robust means the plane falls out of the sky. I still like the KISS philosophy for obvious reasons, but I'm not opposed to adding things to make the software more robust - especially if that's in what I consider a tools/process area as opposed to the software application.

My initial change didn't include the test case you wanted because it was pretty complicated to add...but I agree with your initial question/comments/assessment in terms of expansion of the current workflow.

Tox gives the developer the freedom to test their code locally on a matrix of python versions without much developer overhead: they only need to have the versions installed and only those they're most interested in (e.g. python 2.7.14 and python 3.6.3). Additionally, Python 3 has at least two "tiers" of changes: pre 3.4/post 3.4 and pre 3.6/post 3.6. Given that pytest-falcon supports both python 2 and 3, I think that it makes sense to include tox because in my mind, that means less runs on the free travis build waiting to see if a given python version passes. Having tox setup to run on future versions of python will allow any contributor to see if their changes are future-breaking. Since Python 3 still feels like it's got some churn, I think that is valuable information.

Everyone has time constraints and I'm no different (job, two young kids, family, etc.). I want my tools to work so I can focus on the problems I'm running into with my own code. We use falcon pretty heavily right now, and we're still mostly python 2. Consequently, I cannot write code at this point that takes advantage of the async features of Python 3. However, I've been eyeballing the MagicStack. Given current falcon benchmarks, I've also considered pypy2.

TLDR; I don't mind helping maintain. Will you still be involved or are you really looking to pass the whole thing off to someone else?

yohanboniface commented 6 years ago

My roots are in embedded flight controls software

Fun, I do UAVs stuff these days ;)

Will you still be involved or are you really looking to pass the whole thing off to someone else?

I still have some Falcon stacks running in production, so for now I'll keep an eye. But the direction is moving out to pure python3/asyncio/Roll.