New release pending? / Python >= 3.11 need a compiler when installing

[amotl]

Dear Kenneth,

first things first: Thanks a stack for conceiving and maintaining this excellent package. We are using it for wrapping a HTTP API around Vasuki's core functions for quite a while, and absolutely love it.

Now, we are running into a problem, and hope you will be able to help.

With kind regards,
Andreas.

Problem

• Responder version 2.0.7 has been released 4 years ago, and doesn't work well for us.
• Development head version works for us in development mode, but we can't release Vasuki using that version any longer to PyPI, because of increased constraints compared to the last release in 2023.

  ERROR    HTTPError: 400 Bad Request from https://upload.pypi.org/legacy/
           Can't have direct dependency: responder@ git+https://github.com/kennethreitz/responder.git@e9613500daf ; extra == "service". See
           https://packaging.python.org/specifications/core-metadata for more information.
  

References

• Fix dependencies, using vanilla responder package from PyPI, version 2 daq-tools/vasuki#28

building 'httptools.parser.parser' extension
creating build/temp.linux-x86_64-cpython-311
creating build/temp.linux-x86_64-cpython-311/httptools
creating build/temp.linux-x86_64-cpython-311/httptools/parser
creating build/temp.linux-x86_64-cpython-311/vendor
creating build/temp.linux-x86_64-cpython-311/vendor/http-parser
gcc -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/opt/hostedtoolcache/Python/3.11.9/x64/include/python3.11 -I/tmp/pip-install-mznqineo/httptools_cb5a191155d74385884193c1d772c3df/vendor/http-parser -c httptools/parser/parser.c -o build/temp.linux-x86_64-cpython-311/httptools/parser/parser.o -O2
httptools/parser/parser.c:212:12: fatal error: longintrepr.h: No such file or directory
212 |   #include "longintrepr.h"
    |            ^~~~~~~~~~~~~~~

-- https://github.com/daq-tools/vasuki/actions/runs/9038214344/job/24838867426?pr=28#step:5:218

^^ This is probably coming from an outdated version constraint in responder 2.0.7, which has been fixed already in the development head variant.

[amotl]

Apologies that I've missed to inspect that other report submitted by @michela more closely. It is probably the identical issue.

• Can't install on Debian bookworm with python 3. #518

[amotl]

Hi again,

given that the code base already includes relevant fixes, fixing downstream issues would just be another release away. Let me also tag you, @kennethreitz, as well as @taoufik07, @tomchristie, and @BNMetrics, to humbly ask if anyone of you could make a difference satisfying downstream users?

Thanks a stack in advance!

With kind regards,
Andreas.

[amotl]

Hi there,

can we humbly ask if someone would be able to support downstream users by running a corresponding release? Please let us know if you need any support on this matter, we may be able to lend a hand.

With kind regards,
Andreas.

[amotl]

We just discovered Dyne, a fork of Responder by @tabotkevin.

[kennethreitz]

Dyne is amazing! I am very excited about it. Responder, this project, needs some love and I’m gonna try to give it to it soon. Any help would be appreciated :-)

[amotl]

Hi Kenneth, thanks for your quick reply. Would it be an option to converge Responder users to Dyne, in order to continue contributing there, or does Responder offer anything that is not in Dyne yet, given that it would need additional maintenance efforts?

[tabotkevin]

Hello @amotl, I am glad you love Dyne. I am committed to making it the greatest async web framework.

[amotl]

[...] does Responder offer anything that is not in Dyne yet?

I see. Comparing their dependencies (Responder vs. Dyne), I can see Dyne is a bit heavier, pulling in packages like Pydantic and SQLAlchemy.

In this spirit, and as @tabotkevin responded above (thanks!), Dyne's future will be a full-fledged async web framework, while Responder, after receiving a few cycles of maintenance, can stay what it is and intended to be: A lean and minimal HTTP responder framework? ¹

Footnotes

1. Please correct me if I am wrong with that evaluation, @kennethreitz and @tabotkevin. ↩

[tabotkevin]

@amotl as of now, everything in Responder is still available in Dyne, but Dyne has added support for authentication (Basic, Token, and Digest), request validation, and response serialization (with Marshmallow and Pydantic). It also includes automatic endpoint documentation with OpenAPI and GraphQL support for both Strawberry and Graphene. Essentially, Dyne is a continuous extension of Responder.

[amotl]

I was about to switch Vasuki's minimal HTTP interface over to Dyne, but I am hesitant now, because the additional bells and whistles (and dependencies) of Dyne are just not needed for Vasuki, that's why I loved Responder after discovering it the other day (thanks, @kennethreitz!).

@tabotkevin: I can see where Dyne is going, and I am absolutely eager to try it on another project next time where I will need to use a more complete web framework. Over at cratedb-toolkit, on which I am currently working, I was obviously starting to use fastapi, but I am not married to it, and curious to try out new web frameworks as long as they are not using a router based on Werkzeug, which I don't fancy much. So, good luck with the next development iterations on Dyne, I am looking forward to use it! ¹

Footnotes

1. With a humble but strong wish addressed to you to please tag the Git repository with version numbers vX.X.X, possibly also in retrospective. Thanks! ↩

[kennethreitz]

@amotl do you want to help bring the repository up to date?

[amotl]

Responder, this project, needs some love and I’m gonna try to give it to it soon. Any help would be appreciated :-)

Thanks a stack. I can't promise to be able to submit significant functional contributions, but if you would like to add me as a member to the project ¹ to occasionally give it a hand in maintenance, like dependency and Python version updates (Python 3.13 is out!), running corresponding maintenance releases, and potentially improving and maintaining a CI/GHA configuration, feel free to do so.

Footnotes

1. That is probably not possible with projects on a private account, so it would need to be moved to an organization of any kind? ↩

[tabotkevin]

@amotl Right now, Dyne is using some dependencies, like SQLAlchemy and Strawberry, as dev dependencies. I plan to fix that in the next update. Currently, the only core dependencies are Marshmallow and Pydantic. Dyne's core will remain very lean, and additional features will be introduced through extensions.

[kennethreitz]

@amotl added as a collab!

[kennethreitz]

✨ 🍰 ✨

getting tests to pass is primary goal, as well as updating starlette and python compatibility.

[amotl]

Thanks Kenneth. Let's enumerate and discuss all steps over at...?

• Maintenance 2024-10 #525

[tabotkevin]

@amotl The only core dependencies are Marshmallow and Pydantic. The rest, such as SQLAlchemy, are dev dependencies, which I plan to address in an upcoming update. Dyne's core will remain very lean, and additional features will be introduced through extensions."