Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I forked httpx

tildeweb.nl

Post reply on HN
Print view View original

101–110 of 194 posts

Re: Why I forked httpx

#101

Post by znpy »

globular-toast wrote: post #50
znpy wrote: post #16

Earlier quoted context omitted.

Oh i recognised one of the involved people immediately, drama person. I still think that hijacking the mkdocs package was the wrong way to go though. The foss landscape has become way too much fork-phobic. Just fork mkdocs and go over your merry way.

Right, my suspicion was correct. When I interacted with them a few years ago they seemed perfectly nice and friendly, but seem to have gone off the rails more recently. It's an uncomfortable situation and I've a feeling people are afraid to discuss this kind of thing but we really need to. People are a risk factor in software projects and we need to be resilient to changes they face. Forking is the right way, but pla…

> but places like GitHub have sold people on centralisation. We need to get back to decentralised dev.

I don’t think that’s the case. It’s more of a marketing/market incentive. It’s great pr to be associated with the most famous project, way less so to be associated with a fork, at least until the fork becomes widespread and well recognised.

GitHub does make it fairly easy to fork a project, I wouldn’t blame the situation on github.

Re: Why I forked httpx

#102

Post by troad »

cachius wrote: post #100
Yokohiii wrote: post #65

Earlier quoted context omitted.

I guess frustration speaks here? There is simply no responsibility an OSS maintainer has. They can choose to be responsible, but no one can force them. Eventually OSS licensing is THE solution at heart to solve this problem. Maintainers go rogue? Fork and move on. But surprise, who is going to fork AND maintain? Filling in all the demands from the community, for potentially no benefit? No one can force him to take th…

Right, frustration about the no strings attached sentiment for OSS devs. Of course you've no obligations for support or maintenance, but with increasing exposure responsibility grows as de facto ever more projects, people, softwares depend on you. This doesn't come over night and this is a spectrum and a choice. From purely personal side project over exotic Debian package to friggin httpx with 15k Github stars and 10…

>> Of course you've no obligations for support or maintenance, but with increasing exposure responsibility grows as de facto ever more projects, people, softwares depend on you.

This is an oxymoron. Either you have obligations, or you don't. There's no such thing as having "no obligations" but also "growing responsibility".

I don't understand how you can possibly conclude that just because you've chosen to become dependent on some FOSS library, they owe you anything. You don't get to somehow impose obligations on other people by your choices. They get none of your profits, but they're somehow responsible to you for your business risks? Nonsense.

It is a condition of your use of the code that you've accepted its license, and FOSS licenses are CRYSTAL CLEAR (ALL CAPS) on what obligations or responsibilities the authors have towards you - none whatsoever. Your use of the software is contingent on your acceptance of that license.

If that lack of warranty poses an unacceptable business risk to you, go buy support. Pay a dev to fix the issues you're having, rather than inventing some fictitious responsibility they have to you to do it for free.

Re: Why I forked httpx

#103

Post by WesolyKubeczek »

ayhanfuat wrote: post #8

More related drama: The Slow Collapse of MkDocs ( https://fpgmaas.com/blog/collapse-of-mkdocs/ )

On one hand, that account of the attempted project takeover smelled to me like Jia Tan.

On the other hand, the comments the MkDocs author is making about perceived gender grievances feel so unhinged that I wouldn't be touching anything made by them with a barge pole.

Re: Why I forked httpx

#104

Post by joouha »

This sounds like an ideal use case for modshim [0]

One of its intended use cases is bridging contribution gaps: while contributing upstream is ideal, maintainers may be slow to merge contributions for various reasons. Forking in response creates a permanent schism and a significant maintenance burden for what might be a small change. Modshim would allow you to create a new Python package containing only the fixes for your bugbears, while automatically inheriting the rest from upstream httpx.

[0] https://github.com/joouha/modshim

Re: Why I forked httpx

#107

Post by WesolyKubeczek »

globular-toast wrote: post #3

It's a shame, httpx has so much potential to be the default Python http library. It's crazy that there isn't one really. I contributed some patches to the project some years ago now and it was a nice and friendly process. I was expecting a v1 release imminently. It looks like the author is having some issues which seem to afflict so many in this field for some reason. I notice they've changed their name since I last…

You try to touch low level HTTP with Python, and once you dive into both RFC2616 and Python deep enough, your brain is cooked, basically. Look at what happened to the author of requests, a textbook example.

Or maybe it is that your brain is cooked already, or is on the brink, and your condition attracts you to HTTP and Python, after which it basically has you.

The only way to not go bonkers is to design a library by commitee, so that the disease spreads evenly and doesn't hit any one individual with full force. The result will be ugly, but hopefully free of drama.

Re: Why I forked httpx

#108

Post by functionmouse »

Kwpolska wrote: post #25

What is it about Python that makes developers love fragmentation so much? Sending HTTP requests is a basic capability in the modern world, the standard library should include a friendly, fully-featured, battle-tested, async-ready client. But not in Python, stdlib only has the ugly urllib.request, and everyone is using third party stuff like requests or httpx, which aren't always well maintained. (See also: packaging)

Bram's Law: https://files.catbox.moe/qi5ha9.png

Python makes everything so easy.

Re: Why I forked httpx

#109

Post by robmccoll »

joouha wrote: post #104

This sounds like an ideal use case for modshim [0] One of its intended use cases is bridging contribution gaps: while contributing upstream is ideal, maintainers may be slow to merge contributions for various reasons. Forking in response creates a permanent schism and a significant maintenance burden for what might be a small change. Modshim would allow you to create a new Python package containing only the fixes for…

Since modshim isn't money patching and appears to only be wrapping the external API of a package, if the change is deep enough inside the package, wouldn't you end up reimplementing most of the package from the outside?

Re: Why I forked httpx

#110

Post by lenkite »

ffsm8 wrote: post #74
lenkite wrote: post #32

Earlier quoted context omitted.

Your java knowledge is outdated. Java's JDK has a nice, modern HTTP Client https://docs.oracle.com/en/java/javase/11/docs/api/java.net....

Ahh, java. You never change, even if you're modern HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_1_1) .followRedirects(Redirect.NORMAL) .connectTimeout(Duration.ofSeconds(20)) .proxy(ProxySelector.of( new InetSocketAddress("proxy.example.com", 80) )) .authenticator(Authenticator.getDefault()) .build(); HttpResponse response = client.send(request, BodyHandlers.ofString()); System.out.println(respon…

Your http client setup is over-complicated. You certainly don't need `.proxy` if you are not using a proxy or if you are using the system default proxy, nor do you need `.authenticator` if you are not doing HTTP authentication. Nor do you need `version` since there is already a fallback to HTTP/1.1.

  HttpClient client = HttpClient.newBuilder()
    .followRedirects(Redirect.NORMAL)
    .connectTimeout(Duration.ofSeconds(20))
    .build();
Post reply on HN