Hacker News new | past | comments | ask | show | jobs | submit login
Requests moved to Python Software Foundation (github.com)
111 points by tosh 26 days ago | hide | past | web | favorite | 57 comments



This move is not new. It has been there for a while. Kenneth is the only one committing right now and none of the people who can make new releases are maintaining it. At the moment master is accidentally broken on 2.x, has a bunch of questionable merges in it and CI is failing.

I have been told that the PSF is aware of these issues.


At this point, i am seriously considering using urllib3 instead of this project.


Am I the only one troubled with the fact that the most important third-party library in the Python ecosystem has a git history that looks like that[0]?

[0] https://github.com/psf/requests/commits/master


Given this article, I'm also very confused about this move:

https://vorpus.org/blog/why-im-not-collaborating-with-kennet...


Wow, I had no idea this was the situation.

Is it possible that this move to the PSF is good then? Is Reitz involved in the project at all now?

As a side anecdote, from my own experience with bipolar friends and family that kind of private manipulation + large-scale deception seems sadly familiar. I'm not sure if it's a feature of bipolar disorder or if it's a sad coincidence in our experiences.


>Is Reitz involved in the project at all now?

Judging by the commit history and the README.md, with his name in fancy cursive on top of the PSF logo, this seems to be the Kenneth Reitz Show featuring PSF at best.


>He was deluged with donations from both individuals and large companies like Microsoft, Google, Slack, etc., and the fundraiser total quickly reached ~$30k.

Off topic, but the total looks disgustingly low, if companies like Microsoft, Google, and Slack have donated. Shame on them, they could splurge some more for the FOSS they use...

>On March 15 2018, he contacted me to talk about the fundraiser. He told me he was uncertain what to do with this amount of money – he said his original goal was just to raise $5k to buy a computer. Privately, I was skeptical that the $5k computer had anything to do with Requests. Requests is a small pure-Python library; if you want to work on it, then any cheap laptop is more than sufficient. $5k is the price of a beefy server or top-end gaming rig. But I figured that even if he spent $5k of the money on some unrelated computer, we could call that compensation for his past work, and it would still leave ~$25k to fulfill the promises he'd made in the fundraiser. And this was clearly a great opportunity to build some amazing new stuff. So I didn't say anything about the computer.

Until here, and if it's his project/fundraiser, it's his call. He could have spent it all on blow, and as long as he delivers the end result he raised funds for, it would be totally fine.

What he actually did in the end however (not work at all for the project and expect the volunteer to do it for free while he kept all the money) is a no go...


I’ve heard extremely similar kinds of toxic things about the Anaconda / numpy world too.

Ranging from bizarre religion issues in the workplace to top-down bullying. Not the same e.g. no similar rumors about misused grants or donations, but a lot of creepy comments about management behavior in and around numfocus / anaconda / etc.


links/sources please? Interesting to say the last


What's the relevance between the git history linked to here and the article you linked to?


From the headline I assumed Kenneth "donated" it to get away from all the (entirely self-caused) drama and lay low to rebuild his reputation.

Instead I see he is still on the project, his name is even the first in the README (before the PSF is mentioned). Does he now have a position in PSF? Because that's just inviting problems given his past behaviour.


The git history linked is created by the person is who the article talks about.


Sure, but dredging up a negative article about Kenneth that has nothing to do with a messy git history feels like a witch hunt to me.


This seems like a fitting snippet in relation to a messy git history (full of README changes).

"But none of the money was available to fulfill those commitments; instead, he was going to wait for me to implement the new features for him, and then he needed the entire $28k to pay for writing documentation for my features."


> the most important third-party library in the Python ecosystem has a git history that looks like that[0]?

Your link has a typo: https://github.com/numpy/numpy/commits/master


Thanks! I thought I was the weird one here.


No :)

I'm well aware a suboptimal repository commit history hygiene doesn't necessarily correlate with the actual code quality, but yeah this really doesn't look nice nor convenient to work with. I wonder e.g. what the reason is behind pushing a hundred tiny updates to the README in one day, to master?


They are updating the README files through the github web interface and saving as they update each section.


Why not make all the edits in one pass? It just looks horrendous. I wonder though, is there a git history fixer out there somewhere that rewrites history to merge commits with the same message into one?


`git rebase -i` and then change `pick` to `squash` for the ones you want squashed, but if you’ve pushed all the commits to master you’re now going to have to force-push master, which is... sub-optimal.


Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.


I work in a large monorepo with so many commits you couldn't fathom.

Rebase isn't at all slow. I know this because I do it often to squash my own commits or move things around between branches.


I disagree about it not being slow, it depends on hardware. In addition to that I did not ask about how to fix a commit history manually, I asked for a tool that would go over an entire commit history and automatically fix the issues for me.


The entire comment is:

> Nah, rebase is too slow on large histories and it might not be your own commit which complicates things.

I don't see any questions being asked. Rebase on the commits we're discussing (readme tweaks) are trivial: fixup fixup fixup


> I don't see any questions being asked.

Read the thread next time. I started by asking if there's a fixer and then someone suggests a single command that absolutely doesn't solve the problem and would take enormous time to use on some projects, even more so if your PC isn't the best of the best.


OK, I see your original comment, no need to be rude. If you're working on a computer that struggles with 'making a commit' and 'editing a text file', I feel like you're working in an environment that's going to be very frustrating when writing code.

Are you thinking about rebasing through an IDE? IDEs are uniformly terrible at git.


I just don't like downvotes because people take comments out of context.

I am not thinking about rebasing trough an IDE. Try rebasing in Chromium's repository, it's simply not fast. The thing I asked for is something that would auto-fix the entire commit histories in cases such as the Requests repository, the suggested use of rebase is too tedious and slow. Has something still remained unclear?


Late to the party, but it would be trivial to use `git rebase -i` and a decent editor to fix the Requests commit history. I just gave it a go locally and got good results with less than a minute's editing.


> Try rebasing in Chromium's repository, it's simply not fast

The intent for a tool which could do this quickly is unclear. Rebasing millions of commits will be slow, also rebasing published history will also generate a lot of extra paperwork.

Writing a utility to sort a rebase todo by message and change the later commits with the same message to be fixups is trivial.


No it isn't. Are you thinking about filter-branch?


I am not. Manually issuing rebranch is too slow for any git histories over a few hundred. You'd then also have to find which commits you want to merge, merge them and so on and on. Rebranch basically works if you just want to fix one mistake in history you know you have.


... what? `rebranch` isn't a command in git? I think you mean rebase, and sure, if you were rebasing the entire history it would be slow and awful. But don't do that. Rebase at like `HEAD~10` (or whatever) to only clean up the last 10 commits. There's no performance issues or even management issues. Maybe go read the rebasing section (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) of the git manual...


Yes, autocorrect changed it. So last ten commits isn't slow but I literally asked about entire git history.


Why would you rebase an entire git history? No one is arguing for that.


I... like, the first comment in the thread I asked if there's a tool that could go over the entire git history of a repo and fix such issues up, rebase isn't a solution in that case because it does get slow and it requires manual work which is slow, I don't understand how people are losing the context so quickly here.


Your comment didn't say "the entire git history of a repo", and in the context of this thread, people made the reasonable assumption your were talking about a few sequential commits, as discussed regarding the edits to README on the Requests repo.


You could I suppose but you run the risk of losing your work in the browser. It is a trade off.


“You” are a developer, why the heck are “you” working in a textarea rather than a proper editor? Updating a readme is not the sort of thing that you have to do urgently from a coffee shop while on holiday in South Asia...


Apparently the README is very important for this project. How else could I learn that it's the most downloaded python package and that I can certainly trust it?


you can certianly trust it


Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser.

That doesn’t apply in this case, though, where the README is markdown


> Tbf, a lot of python projects have .rst README files, and getting a local preview can be more of a pain than looking at the GH preview in the browser.

rst may be less popular than md but there's no shortage of local preview options, including plugins/extensions for popular editors.


Even for .rst, the Github editor lets you create a new branch. More likely, they simply didn't feel that was particularly important.


Commit early, commit often...


Git gives you the tools to do that effectively. Namely cheap branching and rebasing. That means you can commit to your heart's content on your own branch, then squash it all down to something useful for master. A hundred tiny commits on a shared branch is just being a bad citizen.


You can do that in a branch without polluting git history.


It makes sense to say backup early, backup often. Commits in a version control system that's meant to keep track of development history aren't really meant to be used as a backup system. Just as a backup system isn't really meant to keep track of development history.


Downgraded from "You can trust this code" to "You may certianly put your trust in this code" in https://github.com/psf/requests/commit/9d4fd3c968b134d98ed27...


By browsing the commit history it becomes clear that the PSF must revoke Kenneth's push access to preserve the integrity of the project.


That feels harsh, but honestly, I think it doesn't make sense for him to have control of master. Let him make branches and do PRs like everyone else. Obviously we know that when he's in the right frame of mind he's a good coder, but when he's not he can easily break master for a hugely popular piece of infrastructure. It doesn't play to his strengths to make him the controller of master.


Looks like what? Seems like just a recent bunch of many fine grained edits to the README...

This however, from TFA, is troubling:

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. If you clone the Requests git repo, you can run git log requests/ to see a list of every time someone changed the library's source code, either directly or by merging someone else's pull request. The last time Reitz did either was in May 2017, when he made some whitespace cleanups.

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.


Not nearly as troubling, but I also had a giggle at this (from README.md):

> You may certianly put your trust in this code.


Wow, that's awful. I've never seen a production project where a developer is allowed to push hundreds of pointless commits directly to master.


Oh my, last 100 or so commits are mostly just Update README.md.


Primarily to add   all over the place.


What’s wrong with it?


Feels like a good home for Requests.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: