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

▲

robmccoll 3 hours ago | parent [-]

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?

	▲	joouha an hour ago \| parent [-]
		Modshim does more than just wrap the external API of a package - it allows you to tweak something internal to the module while leaving its interface alone, without having to re-implement most of the package in order to re-bind new versions of objects. There are a couple of example of this readme: (1) modifing the TextWrapper object but then use it through the textwrap library's wrap() function, and (2) modifing the requests Session object, but then just using the standard requests.get(). Without modshim (using standard monkey-patching) you would have to re-implement the wrap and get methods in order to bind the new TextWrapper / Session classes.