Where should things regarding the project go? The maintainers said to ask a question on Stack Overflow, file an issue on GitHub, or send a message on Twitter.[1]
> 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/ 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.
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.
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.
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"
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.
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.
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/ lists the authors by last name and there are multiple people named "Smith")
> I do not recall that the author of this pamphlet has ever done much
He made the Trio library, which is ridiculously good and also ridiculously hard to implement (just look at this issue [1] for example where he carefully examines the three (!) different async APIs on Windows). Lessons from it are being folded back into the asyncio library in core Python (e.g. exception groups) so everyone benefits even if they don't use Trio directly.
After that debacle with pipenv and the misleading promotion of it, I'm not surprised he's taking time out from Python dev (or perhaps Python is taking time out from him).
For me the issue was less about the bugs in pipenv, and more about how Kenneth Reitz leveraged his commit rights to other projects' documentation to update them to claim that they all recommended pipenv when pipenv was in its infancy.
Sounds like it was a bit more than that, the top comment there looks quite damning:
>However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was.
> And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth as former Python Overlord at Heroku, encouraged Heroku to place Pipenv above Pip as the default Python package manager in the Python buildpack. This decision impacted paying customers and the Python buildpack used a broken version of Pipenv for a long time. So long, most people I know just went back to Pip.
> Then, lastly, when people complained he had a tizzy at reddit and twitter and got PyPA to help backtrack and say "no we didn't support it, nope, its just a thing that happened", all while the main Pipenv Github repository was held under the PyPA GitHub Org.
Basically, Reitz marketed pipenv as _the_ package management tool recommended by Python, by which he meant PyPA, which he was on the board of at the time.
This was displayed prominently on on the front page of the pipenv docs.
After push back, that claim was amended to _the_ package tool recommended by PyPA, not Python.
Then shit blew up on /r/python and someone else from PyPA stepped in to clarify that pipenv was _a_ package tool recommended by PyPA.
And then there was a lot of angry reddit comments, and blog posts.
I wasn't really up to date with Python community drama, but when I had to write a new app in Python, I went looking for something better than pip and a requirements.txt and I chose pipenv, because shit, it was the recommended package management tool for Python, right?
Then I found that pipenv really sucked in many magical and horrible ways, and then the drama about that alleged recommendation broke out.
Anyway, basically, Reitz made claims about pipenv that weren't exactly outright fabrications, but they were very much distorting the truth, people called him on it, he blogged, and then the uptake of pipenv dropped dramatically and people started to realise Poetry was far better.
One issue I experienced was that pipenv would choke and die on dependency graphs that Poetry found to be super easy, barely an inconvenience.
Oh and upgrading Python or pipenv was risky AF because of how closely coupled pipenv was to pip code.
I tried to look it up on a domain purchasing website and it isn't available for purchase, and according to namecheap it is still owned by the same owner since 2011.
Weirdly, when I'm evaluating open source libraries having their own domain name rather than a site on GitHub pages or ReadTheDocs is a very slight mark against them in my book - because of exactly this.
If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come. If it's a relatively concise library I would much rather it use a trustworthy service to host its documentation as opposed to some custom domain that's likely to expire and break links in the future.
(My own open source projects now mostly hang off my https://datasette.io/ domain, but I was a few years into that project before I committed to a domain name that I plan to renew for the rest of my life.)
I almost feel like it's a python specific issue. No other eco system have I've had to scour so many random almost identical looking websites to learn the libraries I use.
Almost like spending lots of time making a documentation page is a rite of passage for python devs.
Of course, some of it may be that I didn't need it as much for when I did java dev. Typing+docstrings help much more in the IDE than for python code.
Also, it's good that most python devs want to document their code. I'd just wish they'd do a better job, and not be so inspired by the crappy official docs.
There is this tool: sphinx. Helps you making documentation + website. Can read you code and document it with your docstrings. Generates some okish documentation and is kind of boilerplate if you create a library.
Sure, for example Rust has rustdoc that does the same thing, but there's a common repository for documentation, kind of like pip is a common repository for libs in Python.
There are connectors for ReadTheDocs to generate the Sphinx docs from GitHub, and probably from elsewhere, too. Yet many projects prefer to host the docs on some random domain.
Just think of it: You start your lib, it becomes fairly popular; you think wow this deserves its own domain. Now it's more like a chore than a pet project, plus no one donates to your awesome lib - yes you believe in OSS, but BigBuckCorp who is using your lib could at least chip in. It is all a drag now, so you decide to move on, you owe them nothing, and they are giving you nothing. So years later your credit card expires, and you have to update it to update the domain, and you will definitely do it if you come to it but not now. And it's gone. Screw this...
I came from Python and C, for me Java has these issues. I almost never find what I want about java libraries, I waste a lot of time this way. I'm sure you could measure this, but I guess we are just used to read code in different ways.
"Duck typed" languages like python always force you to check the documentation three times just to make sure the author doesn't believe that ducks bark, I don't see it ever getting better unless we move away from them entirely.
I heard (somewhere, can't recall where, maybe The Bike Shed podcast with original hosts) it summarised as something like 'python is documented, ruby is tested', (as in library code, not the language itself) which is obviously a ridiculous generalisation/hyperbole, but it does seem to hold somewhat true, that they do more (resp. less) of those things respectively.
Go to Github and do a simple search just to see how many projects are nearing completion, but then dropped at some random point never to be touched again. The README.md is almost always impeccable, and go into great detail about the upcoming plans that were already dropped years ago. Real go-getters, that bunch.
Even better, add "quantum" to your search, and nearly all of them that aren't from the well-known quantum compute companies are like that. They really stand out among their peers. In a laughable way.
Lisp people can't resist getting into something, and then just turning away without notice when they realize they're in over their heads. How many Lisp "books" and "tutorials" are being written over decades now. Especially the quantum ones?
Lisp "tutorials" are the worst because it is so obvious the writer is learning at the same time they're writing. You're basically learning their mistakes as verified gospel. Only once you get some experience, or a better course, do you realize how much those "toots" lead you astray.
Even the YouTube Lisp courses that pretend they are complete aren't. They get about half way through, and then rush through a one pager on OOP programming to end it. Ridiculous.
I love the Lisp language. I really dislike its "meh" culture.
The most famous resource is also probably one of the best. Practical Common Lisp, by Peter Siebel. https://gigamonkeys.com/book/
You can read it for free. But its such a good resource I bought a hard copy and keep it within reach at all times. I like to take notes in the columns, and mark up interesting things I know I'll have to review on occasion.
Last year Peter tweeted out a teaser that he might add some new content to the book, as there has been a lot of progress since this was written. But it is in no way outdated as is.
For some reason, many Python libraries use readthedocs.io, their documentation is sparse, very shallow and the API reference is left undocumented, that I'm usually displeased whenever I see that website and colour scheme. I know that I'm gonna be left wanting. Conversely, the Elixir documentation is so high quality that I'm put in a good mood whenever I land on their version of the documentation browser (generated by ExDoc).
It's not the fault of readthedocs per se, I guess it's what most projects that want a barebones documentation site and call it a day use.
This is something that somewhat plages the Rust ecosystem, since the .rs tld exists. Thankfully, every single library in existence has its docs built automatically and sent to docs.rs, so you don't even need those lib's websites.
They have a use when you follow the git tip to have docs from HEAD and not a release.
It amuses me that I’m implicated in two parts of your comment.
1. I was the first person to use a .rs domain for Rust stuff. I wrote a bit about doing so in https://chrismorgan.info/blog/introducing-teepee/ (heading “Aside: registering .rs domains”). I never finished Teepee, and allowed teepee.rs to lapse (and it hadn’t actually been being used yet, anyway; I would also note that this was from before a lot of the infrastructure we take for granted today existed, including docs.rs).
2. Not every single library has its docs built automatically by docs.rs. For starters, not all crates are on crates.io: some deliberately stick with Git dependencies. But even of things on crates.io, docs.rs will fail to build some, normally due to packager error or some failed FFI linkage (for which the most common solution is to vendor a copy of the foreign library code, either opt-out or opt-in with an instruction for docs.rs to opt in), but it’s possible to deliberately thwart just the building of docs (or even just docs.rs) if you really want to, for which I present another of my transgressions: https://docs.rs/crate/u-plus/latest (source of the prevention: https://git.chrismorgan.info/u-plus/blob/HEAD:/src/lib.rs, lines 4–5).
> Almost like spending lots of time making a documentation page is a rite of passage for python devs.
To be fair Python doesn’t have a good story for declaring static types, IDEs which can guide you as a library-consumer, nor for storing inline documentation/code-doc alongside your functions or classes.
And then all that stuff has to go elsewhere in order for the libraries to be usable.
I like it when it's hosted on the git repo host (e.g. GitHub Pages), which accomplishes that, but my main/usual reason is that it makes it so much easier to find the source/issue tracker/etc.
Otherwise I have to hunt around without knowing whether the link's going to be called 'repository', 'fork me on GitHub' (I don't want to fork you, I just want to see you!), 'homepage', or what.
> Weirdly, when I'm evaluating open source libraries having their own domain name rather than a site on GitHub pages or ReadTheDocs is a very slight mark against them in my book - because of exactly this.
> If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come.
The requests documentation is hosted on ReadTheDocs already. Also you can generate the docs yourself:
Often the domain hosts the email for the package. Control the domain and you can control the package. Control the package and you can ransomware or cryptomime quite a few computers as a criminal. Heck maybe if you are Russian you just wipe any computer with a non-russian IP.
It is funny. The opposite of what you said is true: computers with Russian ips were wiped (by OSS author?) but you are likely do not consider Russians to be human so it should ok in your book.
So this is interesting to me in the context of having just released a Python framework (http://www.tetraframework.com) and choosing to self host the docs.
It's something that I put a lot of thought into, but I decided to go that route for two reasons:
- I want to be able to embed into the docs working examples, as you often see in JavaScript front end framework docs. I could have done this by just embedding a Glitch for each example but I also intend the whole docs site to be a good example of how to build with the framework (once I flesh out routing). 15 years ago when I first found Django, it's site was the perfect reference to look at too see how to use Django in a larger context. (Maybe there is a correlation between proximity of a tool to the front end and self hosted docs)
- There is also a marketing aspect to it, I was to present Tetra as something significant. Show how much thought and work is going into it.
However your comment (and the situation with Requests) has been a nudge, I will be sure to mirror Tetras docs on to a docs hosting site too.
This is a bit ridiculous (not the library, the situation)
Why do we have to reinvent the wheel every couple of years?
As much as this lib looks fine, I'd be sticking with requests if it still keeps getting fixes
And of course the beauty of open source is that I can fork the project and add a fix if I need.
It's great that HttpX uses the same API apparently, but you know, there's always some rough corner somewhere and of course your project hits it. Of course.
Software maintenance is already annoying without having to update libraries every now and then. Now having to replace a library is even more problematic
Yes this. I feel people avoid it because of inertia, but I've started using it by default now, and typically only adds a few lines of code. (old) batteries included etc etc
Funny thing is they chose the exact same domain structure, which reminds me that httpx may eventually end up like this ridiculous requests situation...
I've recently launched a project (https://domainy.io) which lets you monitor for domain names's availability, expiration, purchased etc etc. It's been interesting to see the type of domains that do get expired, though I haven't had a chance to snap up some of them.
At least it's open source. You can still install the library, read (and even vendor) the source code, and build the docs from that code. You just can't visit the website.
This happened to the Celery project a while back.
I was surprised most opensource projects arn't using something like gitlab or hub pages for cheap hosting for docs.
80 comments
[ 3.1 ms ] story [ 155 ms ] thread[1] https://requests.readthedocs.io/en/latest/community/support/
> 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/ 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.
I imagine he’s busy.
I hope he’s enjoying spending time with his spawn.
"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-kennet...
> 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.
- 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/ lists the authors by last name and there are multiple people named "Smith")
So it seems he has in fact "done much".
He made the Trio library, which is ridiculously good and also ridiculously hard to implement (just look at this issue [1] for example where he carefully examines the three (!) different async APIs on Windows). Lessons from it are being folded back into the asyncio library in core Python (e.g. exception groups) so everyone benefits even if they don't use Trio directly.
[1] https://github.com/python-trio/trio/issues/52
>However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was.
> And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth as former Python Overlord at Heroku, encouraged Heroku to place Pipenv above Pip as the default Python package manager in the Python buildpack. This decision impacted paying customers and the Python buildpack used a broken version of Pipenv for a long time. So long, most people I know just went back to Pip.
> Then, lastly, when people complained he had a tizzy at reddit and twitter and got PyPA to help backtrack and say "no we didn't support it, nope, its just a thing that happened", all while the main Pipenv Github repository was held under the PyPA GitHub Org.
This was displayed prominently on on the front page of the pipenv docs.
After push back, that claim was amended to _the_ package tool recommended by PyPA, not Python.
Then shit blew up on /r/python and someone else from PyPA stepped in to clarify that pipenv was _a_ package tool recommended by PyPA.
And then there was a lot of angry reddit comments, and blog posts.
https://www.reddit.com/r/Python/comments/8jd6aq/why_is_pipen...
https://web.archive.org/web/20180519001601/http://journal.ke...
I wasn't really up to date with Python community drama, but when I had to write a new app in Python, I went looking for something better than pip and a requirements.txt and I chose pipenv, because shit, it was the recommended package management tool for Python, right?
Then I found that pipenv really sucked in many magical and horrible ways, and then the drama about that alleged recommendation broke out.
Anyway, basically, Reitz made claims about pipenv that weren't exactly outright fabrications, but they were very much distorting the truth, people called him on it, he blogged, and then the uptake of pipenv dropped dramatically and people started to realise Poetry was far better.
One issue I experienced was that pipenv would choke and die on dependency graphs that Poetry found to be super easy, barely an inconvenience.
Oh and upgrading Python or pipenv was risky AF because of how closely coupled pipenv was to pip code.
Requests requires the ability to make regular updates to maintain security. It's unsuitable for inclusion in the standard library.
I tried to look it up on a domain purchasing website and it isn't available for purchase, and according to namecheap it is still owned by the same owner since 2011.
If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come. If it's a relatively concise library I would much rather it use a trustworthy service to host its documentation as opposed to some custom domain that's likely to expire and break links in the future.
(My own open source projects now mostly hang off my https://datasette.io/ domain, but I was a few years into that project before I committed to a domain name that I plan to renew for the rest of my life.)
Almost like spending lots of time making a documentation page is a rite of passage for python devs.
Of course, some of it may be that I didn't need it as much for when I did java dev. Typing+docstrings help much more in the IDE than for python code.
Also, it's good that most python devs want to document their code. I'd just wish they'd do a better job, and not be so inspired by the crappy official docs.
There do all these websites come from.
There are connectors for ReadTheDocs to generate the Sphinx docs from GitHub, and probably from elsewhere, too. Yet many projects prefer to host the docs on some random domain.
The overwhelming majority of Python projects (and many non-Python projects as well) host their documentation/website on projectname.rtfd.io
Go to Github and do a simple search just to see how many projects are nearing completion, but then dropped at some random point never to be touched again. The README.md is almost always impeccable, and go into great detail about the upcoming plans that were already dropped years ago. Real go-getters, that bunch.
Even better, add "quantum" to your search, and nearly all of them that aren't from the well-known quantum compute companies are like that. They really stand out among their peers. In a laughable way.
Lisp people can't resist getting into something, and then just turning away without notice when they realize they're in over their heads. How many Lisp "books" and "tutorials" are being written over decades now. Especially the quantum ones?
Lisp "tutorials" are the worst because it is so obvious the writer is learning at the same time they're writing. You're basically learning their mistakes as verified gospel. Only once you get some experience, or a better course, do you realize how much those "toots" lead you astray.
Even the YouTube Lisp courses that pretend they are complete aren't. They get about half way through, and then rush through a one pager on OOP programming to end it. Ridiculous.
I love the Lisp language. I really dislike its "meh" culture.
Where, please where, should I be learning Lisp? I'm getting deeper and deeper into Org mode and with that the whole Emacs train.
You can read it for free. But its such a good resource I bought a hard copy and keep it within reach at all times. I like to take notes in the columns, and mark up interesting things I know I'll have to review on occasion.
Last year Peter tweeted out a teaser that he might add some new content to the book, as there has been a lot of progress since this was written. But it is in no way outdated as is.
It's not the fault of readthedocs per se, I guess it's what most projects that want a barebones documentation site and call it a day use.
It's commonly used to divert attention from what really matters...
So, I appreciate Python bare bones documentation. Easier to judge its true value.
They have a use when you follow the git tip to have docs from HEAD and not a release.
1. I was the first person to use a .rs domain for Rust stuff. I wrote a bit about doing so in https://chrismorgan.info/blog/introducing-teepee/ (heading “Aside: registering .rs domains”). I never finished Teepee, and allowed teepee.rs to lapse (and it hadn’t actually been being used yet, anyway; I would also note that this was from before a lot of the infrastructure we take for granted today existed, including docs.rs).
2. Not every single library has its docs built automatically by docs.rs. For starters, not all crates are on crates.io: some deliberately stick with Git dependencies. But even of things on crates.io, docs.rs will fail to build some, normally due to packager error or some failed FFI linkage (for which the most common solution is to vendor a copy of the foreign library code, either opt-out or opt-in with an instruction for docs.rs to opt in), but it’s possible to deliberately thwart just the building of docs (or even just docs.rs) if you really want to, for which I present another of my transgressions: https://docs.rs/crate/u-plus/latest (source of the prevention: https://git.chrismorgan.info/u-plus/blob/HEAD:/src/lib.rs, lines 4–5).
To be fair Python doesn’t have a good story for declaring static types, IDEs which can guide you as a library-consumer, nor for storing inline documentation/code-doc alongside your functions or classes.
And then all that stuff has to go elsewhere in order for the libraries to be usable.
Otherwise I have to hunt around without knowing whether the link's going to be called 'repository', 'fork me on GitHub' (I don't want to fork you, I just want to see you!), 'homepage', or what.
> If a project has its own domain name, it has better be VERY confident that it will be renewing that domain for decades to come.
The requests documentation is hosted on ReadTheDocs already. Also you can generate the docs yourself:
https://github.com/psf/requests/blob/main/docs/Makefile#L25
I find your focus on the domain kind of odd to be honest. I'm not really sure why it's so important.
It's something that I put a lot of thought into, but I decided to go that route for two reasons:
- I want to be able to embed into the docs working examples, as you often see in JavaScript front end framework docs. I could have done this by just embedding a Glitch for each example but I also intend the whole docs site to be a good example of how to build with the framework (once I flesh out routing). 15 years ago when I first found Django, it's site was the perfect reference to look at too see how to use Django in a larger context. (Maybe there is a correlation between proximity of a tool to the front end and self hosted docs)
- There is also a marketing aspect to it, I was to present Tetra as something significant. Show how much thought and work is going into it.
However your comment (and the situation with Requests) has been a nudge, I will be sure to mirror Tetras docs on to a docs hosting site too.
Why do we have to reinvent the wheel every couple of years?
As much as this lib looks fine, I'd be sticking with requests if it still keeps getting fixes
And of course the beauty of open source is that I can fork the project and add a fix if I need.
It's great that HttpX uses the same API apparently, but you know, there's always some rough corner somewhere and of course your project hits it. Of course.
Software maintenance is already annoying without having to update libraries every now and then. Now having to replace a library is even more problematic
the new library is a natural evolution that for example features full async support, which I don't think will ever be added to requests.
There's also https://docs.python.org/3/library/http.client.html, which ironically refers people over to requests anyway...
Yet, this is just one more example against reliying on third-party libraries for production purposes. Sometimes, urllib is enough.