5 ms·

From https://github.com/psf/requests/issues/6140 https://github.com/psf/requests/issues/6140: > The domain is still owned by Kenneth and the maintainers haven'

by di 4y ago

From https://github.com/psf/requests/issues/6140 https://github.com/psf/requests/issues/6140: > The domain is still owned by Kenneth and the maintainers haven't had access to it in quite some time. and: > For those looking for alternatives, https://requests.readthedocs.io/en/latest/ https://requests.readthedocs.io/en/latest/ should be returning docs correctly again. This has been the "official" location for some time as we lack controls on the python-requests domains. I'll update again once we receive a response from Kenneth.

pyuser583 4y ago
According to Kenneth’s Twitter feed, be became a dad about about 50 days ago. I imagine he’s busy.
- OJFord 4y ago
  He sort of 'rage quit' well before that, handed everything off to the first to request it. Not great, but his prerogative, something to bare in mind relying on OSS from random individuals I suppose, even if it is something as major as requests (and someone as major as Reitz) et al.
  - ksaj 4y ago
    It's the same as our recent FOSS library security gaffe. Entirely maintained by one guy, yet relied upon by way too many people not willing to throw in some funds for its upkeep.
  - pyuser583 4y ago
    Judging by his now-deleted tweets, he’s had a hectic life. I hope he’s enjoying spending time with his spawn.
    - boopmaster 4y ago
      hopefully it’s more enjoyment than you’ve derived by frolicking around in his creative outputs before tossing out hot takes about his personal life.
smcl 4y ago
Yeah he's only sort of connected to the project now: "I think a lot of people don't realize how little Reitz actually has to do with Requests development. For many years now, actual maintenance has been done almost exclusively by other volunteers. If you look at the maintainers list on PyPI, you'll see he doesn't have PyPI rights to his own project, because he kept breaking stuff, so the real maintainers insisted on revoking his access" From https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...
- fnLkq 4y ago
  Much of this applies perfectly to CPython and many of the CPython core "developers". I do not recall that the author of this pamphlet has ever done much, but he tends to appear whenever someone is canceled.
  - oblio 4y ago
    Why there, brave anonymous commenter from a throwaway account, what do you have to say about his core concerns? > At least as far as commits go, his main contributions since then appear to consist of merging some small doc fixes, and monetizing the project by adding donation links, ads, intrusive sponsored links, etc. All of this money goes directly into his pocket, not the project's maintainers. > I also learned that he has a history of selling premium support contracts for Requests, where he took the money and then delegated the actual work to unpaid volunteers. > I don't have any objection to trying to make money from open-source. I've written before about how open-source doesn't get nearly enough investment. I do object to exploiting volunteers, driving out community members, and lying to funders and the broader community. Reitz has a consistent history of doing all these things. They're quite serious and the blog post seems quite convincing.
  - faho 4y ago
    He's listed as the (co-)author on a number of PEPs: - PEP 533 – Deterministic cleanup for iterators - PEP 518 – Specifying Minimum Build System Requirements for Python Projects - PEP 517 – A build-system independent format for source trees - PEP 465 – A dedicated infix operator for matrix multiplication - PEP 600 – Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions - PEP 8016 – The Steering Council Model - PEP 568 – Generator-sensitivity for Context Variables (and that's as far as I cared to look - unfortunately https://peps.python.org/ https://peps.python.org/ lists the authors by last name and there are multiple people named "Smith") So it seems he has in fact "done much".
dagurp 4y ago
Given how popular it is, would it be a bad idea to include it in the standard library?
- Ancapistani 4y ago
  "The standard library is where packages go to die." Requests requires the ability to make regular updates to maintain security. It's unsuitable for inclusion in the standard library.

by di 4y ago

pyuser583 4y ago

According to Kenneth’s Twitter feed, be became a dad about about 50 days ago. I imagine he’s busy.

OJFord 4y ago
He sort of 'rage quit' well before that, handed everything off to the first to request it. Not great, but his prerogative, something to bare in mind relying on OSS from random individuals I suppose, even if it is something as major as requests (and someone as major as Reitz) et al.
- ksaj 4y ago
  It's the same as our recent FOSS library security gaffe. Entirely maintained by one guy, yet relied upon by way too many people not willing to throw in some funds for its upkeep.
- pyuser583 4y ago
  Judging by his now-deleted tweets, he’s had a hectic life. I hope he’s enjoying spending time with his spawn.
  - boopmaster 4y ago
    hopefully it’s more enjoyment than you’ve derived by frolicking around in his creative outputs before tossing out hot takes about his personal life.

smcl 4y ago

Yeah he's only sort of connected to the project now: "I think a lot of people don't realize how little Reitz actually has to do with Requests development. For many years now, actual maintenance has been done almost exclusively by other volunteers. If you look at the maintainers list on PyPI, you'll see he doesn't have PyPI rights to his own project, because he kept breaking stuff, so the real maintainers insisted on revoking his access" From https://vorpus.org/blog/why-im-not-collaborating-with-kenneth-reitz/ https://vorpus.org/blog/why-im-not-collaborating-with-kennet...

fnLkq 4y ago
Much of this applies perfectly to CPython and many of the CPython core "developers". I do not recall that the author of this pamphlet has ever done much, but he tends to appear whenever someone is canceled.
- oblio 4y ago
  Why there, brave anonymous commenter from a throwaway account, what do you have to say about his core concerns? > At least as far as commits go, his main contributions since then appear to consist of merging some small doc fixes, and monetizing the project by adding donation links, ads, intrusive sponsored links, etc. All of this money goes directly into his pocket, not the project's maintainers. > I also learned that he has a history of selling premium support contracts for Requests, where he took the money and then delegated the actual work to unpaid volunteers. > I don't have any objection to trying to make money from open-source. I've written before about how open-source doesn't get nearly enough investment. I do object to exploiting volunteers, driving out community members, and lying to funders and the broader community. Reitz has a consistent history of doing all these things. They're quite serious and the blog post seems quite convincing.
- faho 4y ago
  He's listed as the (co-)author on a number of PEPs: - PEP 533 – Deterministic cleanup for iterators - PEP 518 – Specifying Minimum Build System Requirements for Python Projects - PEP 517 – A build-system independent format for source trees - PEP 465 – A dedicated infix operator for matrix multiplication - PEP 600 – Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions - PEP 8016 – The Steering Council Model - PEP 568 – Generator-sensitivity for Context Variables (and that's as far as I cared to look - unfortunately https://peps.python.org/ https://peps.python.org/ lists the authors by last name and there are multiple people named "Smith") So it seems he has in fact "done much".

dagurp 4y ago

Given how popular it is, would it be a bad idea to include it in the standard library?

Ancapistani 4y ago
"The standard library is where packages go to die." Requests requires the ability to make regular updates to maintain security. It's unsuitable for inclusion in the standard library.