requests icon indicating copy to clipboard operation
requests copied to clipboard

psf to take over request/toolbelt project?

Open RosterIn opened this issue 3 years ago • 6 comments
trafficstars

requests project was moved to psf however there was another project toolbelt https://github.com/requests/toolbelt which is not maintained. according to https://github.com/requests/toolbelt/issues/322 it's suggested that psf might transfer ownership as it make sense that requests-toolbelt will be with same ownership as requests

What is psf take on this?

RosterIn avatar Aug 25 '22 11:08 RosterIn

Agree. Or merge it into requests Such as the ability below which is used by lots of users.

If you are sending a very large file as a multipart/form-datarequest , you may want to stream the request. requestsNot supported by default , but a third-party package is supported. You can read [the toolbelt](https://toolbelt.rtfd.org/)[ documentation](https://toolbelt.rtfd.org/) to learn how to use it.requests-toolbelt

wqh17101 avatar Aug 25 '22 11:08 wqh17101

No one on that thread is involved with the project or the PSF

sigmavirus24 avatar Aug 25 '22 13:08 sigmavirus24

@sigmavirus24 How about merge it and remove https://github.com/requests/toolbelt

wqh17101 avatar Aug 25 '22 13:08 wqh17101

This library is under feature freeze so merging it would violate that. Additionally a lot of things in the toolbelt are niché use cases or proofs if concept for others to build on top of, not things that belong in requests. As it is the streaming multipart form data encoder is being moved into urllib3 to be more generally useful. I believe that's what 99% of toolbelt users need it for anyway.

sigmavirus24 avatar Aug 25 '22 15:08 sigmavirus24

The thing is that there is no alternative for toolbelt. This is why i asked here if psf has intentions of taking over this sub-project too.

RosterIn avatar Sep 04 '22 11:09 RosterIn

This is why i asked here if psf has intentions of taking over this sub-project too

It has never been a sub-project. It's where I started collecting recipes for things people were often wanting but which don't belong in this project. It's never been a particularly high priority for me.

I also don't think people understand that moving organizations in GitHub doesn't change maintenance or the people involved (presently just me). The psf doesn't magic contributors who provide patches or people to help maintain.

sigmavirus24 avatar Sep 04 '22 12:09 sigmavirus24

@sigmavirus24 I understand your point about maintaining the API. The toolbelt might get more help if it's moved into the psf org.

Just my thought, feel free to ignore as needed. :)

achapkowski avatar Sep 29 '22 13:09 achapkowski

I can add people to the requests org if people care about the project but it sounds like people care more about joining the psf org and not the project. To be clear, the largest code of any value in the toolbelt will be in urllib3 v2.0. I'm not convinced the effort of moving the project is worth anything.

sigmavirus24 avatar Sep 29 '22 13:09 sigmavirus24

@sigmavirus24 Speaking as a fellow urllib3 maintainer here, I know we need to get your PR merged for urllib3 v2.0 but in the meantime I would be happy to have maintainers right on the toolbelt repo and the PyPI package to fix the urllib3 warnings that it's currently emitting. I agree that moving to the psf org isn't needed and to be clear I'm also not promising to fix any other issues.

What do you think?

pquentin avatar Sep 29 '22 14:09 pquentin

I'll add you as soon as I'm able @pquentin

sigmavirus24 avatar Sep 29 '22 14:09 sigmavirus24

I'll help maintain the package as well.

achapkowski avatar Sep 29 '22 15:09 achapkowski

Thank you @sigmavirus24!

@achapkowski I'm sure help will be needed to review PRs, fix CI, support new Python versions, etc.

pquentin avatar Sep 30 '22 07:09 pquentin

@pquentin cool, send stuff my way!

achapkowski avatar Sep 30 '22 18:09 achapkowski

With help from @achapkowski and @sigmavirus24 I released requests-toolbelt 0.10.0 today. There is no new work in it, it only contains all the fixes that were merged since 0.9.1, as well as a new feature, hence the bump to 0.10.0.

I think this issue can now be closed.

pquentin avatar Oct 07 '22 06:10 pquentin