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.
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.
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.
There do all these websites come from.
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.
They have a use when you follow the git tip to have docs from HEAD and not a release.
> 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.
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.
There's also https://docs.python.org/3/library/http.client.html, which ironically refers people over to requests anyway...
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.
> 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 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...
I imagine he’s busy.
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.
Yet, this is just one more example against reliying on third-party libraries for production purposes. Sometimes, urllib is enough.
