The domain for the Python Requests library is expired | Hacker News Reader

The domain for the Python Requests library is expired

docs.python-requests.org

170 pointsdavidgu79 comments

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.

There do all these websites come from.

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.

> 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

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.

Just use types. At this point it's "I don't like how the blunt edge of this knife won't cut well".

And how do you tell that the library authors?

Pull request.

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.

There's unfortunately a lot of SEO spam dressed as docs in the python world. Usually all you need is in readthedocs.

If you're using Github you don't even need RTD. You can host a Sphinx site direct from GH without the sluggishness and theming of RTD.

Ruby I have found to be incredibly difficult in this regard as well.

It's been a Common Lisp problem forever.

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.

Thank you for posting this.

Where, please where, should I be learning Lisp? I'm getting deeper and deeper into Org mode and with that the whole Emacs train.

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.

Terrific, thank you!

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.

I actually find too much aesthetics work rather distracting.

It's commonly used to divert attention from what really matters...

So, I appreciate Python bare bones documentation. Easier to judge its true value.

I thought readthedocs was just documentation hosting? If I remember correctly, the actual documentation generation is done with Sphinx.

I stand corrected, then my issues are with the incomplete Sphinx docs I often see shipping with Python libraries.

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.

python supports type hints and IDEs can use those hints as well as document genration

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:

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.

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.

From 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/ 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.

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

I imagine he’s busy.

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.

Judging by his now-deleted tweets, he’s had a hectic life.

I hope he’s enjoying spending time with his spawn.

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.

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-kennet...

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")

So it seems he has in fact "done much".

> 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.

[1] https://github.com/python-trio/trio/issues/52

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 those of us out of the loop: what debacle with pipenv?

Perhaps see this past discussion: https://news.ycombinator.com/item?id=18612590

that doesnt explain anything -- pipenv was broken? So? Its an open source project, it will have issues now and then.

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.

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.

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

"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.

Recommended alternative: https://www.python-httpx.org

Yep! I've been using httpx for all my projects and several are in production. It's a great replacement

Too bad you'll still end up with requests as part of some other package's dependency most of the time.

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

requests has laid all the groundwork for httpx to be able to even exist.

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.

Depending on your needs, urllib might be good enough.

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

There's also https://docs.python.org/3/library/http.client.html, which ironically refers people over to requests anyway...

Yes! https://github.com/gabrielsroka/r

Funny thing is they chose the exact same domain structure, which reminds me that httpx may eventually end up like this ridiculous requests situation...

This was recently an issue with the celery docs site too. When the primary authors step away from the code the infra isn’t always handed over.

i had some problem with celery a few days ago, this cant be coincidence. Thanks for the info.

Yeah, celery docs were down for weeks earlier this year and now has a new domain.

Backstory on the above: https://github.com/celery/celeryproject/issues/52, https://twitter.com/auvipy/status/1506560289117933568, https://twitter.com/auvipy/status/1507254618954207235

What does it mean that the domain has expired?

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.

To clarify, it's not expired, the registrar is asking Kenneth to verify his identity. We're currently pending that before it's available again.

GitHub issue: https://github.com/psf/requests/issues/6140

Im curious how this is a valid issue for that repository, the repository seems to make no reference to that domain

The requests repository isn’t connected to Python-requests? Maybe take another look, haha.

I would argue that the repository should only pertain to things regarding the repository, not the project as a whole

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]

[1] https://requests.readthedocs.io/en/latest/community/support/

The only official connection is that site holding translations to the docs hosted on RTD.

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.

Requests not being async is a pretty big remark against it in my book. I am still using it for testing and sync requests but moved to aiohttp mostly.

Too bad, requests is a very popular and useful library.

Yet, this is just one more example against reliying on third-party libraries for production purposes. Sometimes, urllib is enough.

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.

requests.dev is on sale for $174

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.

Reply on news.ycombinator.com