Inherit HTTPConnection through urllib3.connection, not httplib

[mupuf]

By inheriting from urllib3.connection.HTTPConnection (that inherits from httplib.HTTPConnection itself), we can adapt to the internal changes in urllib3 2.0 that added a request() method that is incompatible with httplib.HTTPConnection.request.

This fixes the incompatibility between urllib3 2.0 and requests 1.26+, which was the first version that stopped vendoring urllib3.

Reference: docker/docker-py#3113 (comment)

[mgorny]

Thanks for figuring this out. I can confirm that with this patch, tests on both requests-unixsocket itself and on cheroot (using requests-unixsocket) pass. I'm going to carry it into Gentoo.

[webknjaz]

@mupuf could you add Fixes #70 somewhere in the PR description?

[webknjaz]

@msabramo this is a fix to a far-reaching issue. Would you mind merging it?

[webknjaz]

Pretty sure this is wrong: the project version is produced from Git tags via pbr. Besides, the version on PyPI is 0.3.0 already.

[mupuf]

Right, this was never intended to end up here. That's what I get for using master for a PR!

[mupuf]

/me just wanted to make a release in his fork, until a new release was made upstream.

I also did not expect it would take so long to actually land.

[webknjaz]

Ah, makes sense. Have you checked if installing from Git URLs would work if you make a tag in your fork? Also, you could make a dumb-pypi index on GH Pages with a custom build and install from there.

FWIW I checked the maintainer's profile and it seems to be rarely used. So I wrote emailed them yesterday about this with suggestions. No reply so far.

[oschwartz10612]

Yes, @msabramo this is effecting our key applications. Can confirm the patch works in production. Merging would be appreciated.

[olemoign]

@msabramo Can you please merge this or give the rights to somebody to do it?

[thebaptiste]

@msabramo Can you please merge this or give the rights to somebody to do it?

Yes please, this a problem for me too. I would appreciate a merge and then a new release on pypi.

[thebaptiste]

@mupuf May be you could create a tag 0.3.1 or 0.4.0 (greater than release 0.3.0 on pypi) in your forked repo mupuf/requests-unixsocket ?
So I could use this tag with a git+https requirement on your repo. Of course, I could create my own fork, but as this fix is yours I would prefer to use your fork than mine !

[mupuf]

@mupuf May be you could create a tag 0.3.1 or 0.4.0 (greater than release 0.3.0 on pypi) in your forked repo mupuf/requests-unixsocket ? So I could use this tag with a git+https requirement on your repo. Of course, I could create my own fork, but as this fix is yours I would prefer to use your fork than mine !

Already done in May: https://github.com/mupuf/requests-unixsocket/releases/tag/v0.2.1

[thebaptiste]

Already done in May: https://github.com/mupuf/requests-unixsocket/releases/tag/v0.2.1

Indeed, but 0.2.1 is lesser than 0.3.0 on pypi (even if this tag 0.3.0 should not be missing in git), so may be it's a little confusing to update from 0.3.0 (from pypi) to 0.2.1 (from git).
Thanks anyway for your fix, it works fine and allow me to use requests-unixsocket with the last releases of both requests and urllib3

[cquike]

This is urgently needed by many projects who get errors by its users who pull the last version of requests-unixsocket from pypi. @msabramo : do you think there is something holding off the merging of this?
Thanks!

[erjoalgo]

+1 I am affected by this.

[erjoalgo]

I worked around this error using the following one-liner, which asks pip to install the fix from this branch:

pip install git+https://github.com/mupuf/requests-unixsocket --break-system-packages

Hopefully the fix will be merged soon.

[webknjaz]

Don't throw --break-system-packages around. Somebody is going to copy this and break their system one day. If one needs it for whatever reason, they'll add this option.

[webknjaz]

@mupuf how you feel about sticking your fork into some shared maintenance org and setting up publishing to PyPI under a different project name, like requests-unixsocket-urllib3-v2? Could move to one of the existing orgs or make a new one...

[mupuf]

@webknjaz: I agree, it is time for someone to fork this project and become the new maintainer. This person won't however be me, so feel free to step up :)

[webknjaz]

@mupuf I'm not talking about full maintenance, just publishing this patch and having a mechanism for letting other people start maintaining the thing. I also don't need to maintain it beyond making it installable from a more permanent location...

[oschwartz10612]

I have reached out to @msabramo over the email listed on his profile. I will let you know if I hear back. If needed, I can fork and setup publishing so we all can pull from a reliable source.

[crgwbr]

Any update on getting this fix merged and released? Could we perhaps convince PSF (since they already control requests) or Jazzband to take over this project?

[webknjaz]

Jazzband won't accept it. I asked. There should still be a project leader and willingness to transfer.

[olemoign]

For what it's worth:
https://github.com/parsys-telemedicine/requests-unixsocket (diff is only the fix)
https://pypi.org/project/parsys-requests-unixsocket/

[kloczek]

it would be really good to merge this PR and release new version.

[crgwbr]

Since this project seems to be abandoned, but its longevity is important to my team, we've forked the project as requests-unixsocket2. It should be a drop in replacement for this package.

• PyPI: https://pypi.org/project/requests-unixsocket2/0.4.0/
• Repository: https://gitlab.com/thelabnyc/requests-unixsocket2
• Clone of this PR: https://gitlab.com/thelabnyc/requests-unixsocket2/-/merge_requests/1

We've migrated this PR there, merged it, and released to PyPI as part of v0.4.0.

[mgorny]

Since this project seems to be abandoned, but its longevity is important to my team, we've forked the project as requests-unixsocket2. It should be a drop in replacement for this package.

Are you planning to actively maintain the project going forward, or just keep it alive? If the former, why not open a PEP 541 request to take the original name? They take around forever to process, so the sooner the better.

[crgwbr]

We're using it production on several actively developed projects, so I anticipate keeping it compatible with up-to-date requests/urllib3. But we're not at the moment looking to add a ton of new features/refactoring/etc, if that's what you mean. PRs are of course welcome if you have something in mind.

[simondeziel]

@crgwbr if you could take over the original name as suggested by @mgorny that'd ensure a smooth transition for everyone.

[cquike]

Taking over the original name would probably also alleviate some transition pains for downstream. See for instance this Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2284361

[erjoalgo]

The previous fork by mupuf appeared to stop working for me, so I'm now using:

pip install git+https://gitlab.com/thelabnyc/requests-unixsocket2

from this comment

[crgwbr]

fwiw, @erjoalgo, you don't need to install as a git dependency. We're publishing the fork to PyPI (https://pypi.org/project/requests-unixsocket2/), so you can just do this:

pip install requests-unixsocket2