Swap out `requests` to avoid LGPL dependency

[ashb]

This library depends upon requests, and while requests itself is Apache 2 licensed, it depends upon chardet which is LGPL'd.

This leads to confusing licensing situations for projects using this python docker client, and it is the view of the Apache Software Foundation that any LGPL dep places some restrictions on the downstream projects, and thus has to be avoided.

(This also depends upon websocket client, which is currently LGPLd, but they are considering a new license so that problem may be solved for us)

See psf/requests#5797 for the latest attempt to change the dependency upstream (which at the time of writing appears to be a Wont Fix, so I closed the PR)

So: I would like to propose that requests is switched out to httpx library -- it is broadly API compatible with requests.

I am happy to attempt this PR, but first I wanted to raise the issue and see if a PR will be accepted!

As this still supports Python2, we might have to only use httpx for Python3, and keep requests in use for Python 2.7, unless there are also plans to drop 2.7 support since it is no longer supported by Python upstream since January 1st 2021?

[ashb]

Should this have been raised against https://github.com/kubernetes-client/python-base instead?

[tomplus]

The library is generated by https://github.com/OpenAPITools/openapi-generator so you should submit the issue/pr there.

[ashb]

The use of requests appears to be in https://github.com/kubernetes-client/python-base/blob/8a969ee9ad2837528c19673cfb5127b47be03105/config/kube_config.py which I think is not generated, right?

[tomplus]

You are right, but I think it's more complicated, python-base uses for example google-auth and requests-oauthlib which use requests...

[mik-laj]

for example google-auth

Gogolle-auth also support urrlib as transport.

requests-oauthlib

We may consider migrating to authlib.

[roycaihw]

cc @palnabarun mentioned a similar conversation happened in the past

[palnabarun]

We discussed a while back to keep only one of the requests or urllib3. I feel like it's a fair ask to remove requests.

Although, I am not very comfortable roping in httpx. Can we use urllib3 instead to replace requests, since urllib3 is already a dependency? WDYT?

Would you be willing to make the same change in python-base?

[ashb]

I could look at changing this in python-base, sure.

That said, it looks like the requests maintainers might be willing to merge the PR where we replaced the LGPL'd dep. Would you still like this change made if they do accept it?

[palnabarun]

We were thinking of removing the dependency on requests for some time now. We would really love to have some helping hands.

Would you still like this change made if they do accept it?

Yup, removing requests in favor of urllib3 would still be something that we would do.

[ashb]

Got it. I'll add it to my list of side projects -- can't promise when I'll get around to it though.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten