Is it bad form to patch a dependency?
from staircase@programming.dev to programming@programming.dev on 01 Apr 17:30
https://programming.dev/post/48132412
from staircase@programming.dev to programming@programming.dev on 01 Apr 17:30
https://programming.dev/post/48132412
My code depends on a library that makes liberal use of patching (replacing text in source code) for its own dependencies. I feel this is bad form, because, for example, that dependency may now conflict irreconcilably with another dependency of mine.
Am I right in thinking patching code is bad form?
#programming
threaded - newest
Is this for a personal project or something to be distributed?
If this is a distributed project where reproducibility is important, modifying external dependencies will quickly and greatly complicate things. I think a preferred method would be forking if not doing a pull request, assuming those dependencies are open source. This way you can independently develop on the dependency and source it separately instead of relying on patches
I’m writing a library, to be distributed, and the library I’m depending on - that patches - is also intended to be distributed.
Patching is a reasonable temporary solution while you are actively working to get the patch merged upstream. If you’re not doing that, a better solution is to fork. If you’re not doing that either, then you should be updating your resume.
through patching?
If your patching an external library, please try to do what you can in the moment to formulate the patch in such a way that the upstream can accept it.
Not sure if it’s clear, but I’m not doing the patching - my dependency is.
Updated post to make it clearer.
This would depend on the language/ecosystem. It’s worse for C and C++ than for example Rust because of packaging policies and ease of distributability.
Hmmm, it’s C++
Then you could be forced to vendor everything. And if it’s open-source and relevant for distros to pickup, then you will need to find out if distros would be willing to take your library with its vendored libs (or package them separately just for your library)…etc.
And you may need to figure out if there are bus factor concerns with your direct dependency, since such libraries are not necessarily maintenance free, even from a mere compiling/building stand point (what if a patched indirect dependency no longer builds with new compilers…etc).
If the dependency static links the library and doesn’t use structs or classes defined in it for its interface then it is fine. If either of those are not true it is asking for trouble
Patching a library is fine if you’re building a final executable — something where you know what the final dependency graph looks like ahead of time.
It’s not fine if you’re building a library. You don’t know if a consumer will also want to use an unpatched version of that library, and depending on the scenario that could result in duplicated instances (each with their own internal state), failure to build or load, or mismatches in data layout or function definitions.
I would avoid using a library like that if I could.
Of course, sometimes the person who can make that decision is the creator of npm itself, and says “No I don’t believe I will”: github.com/isaacs/jackspeak/issues/20
Yes and no. It depends on how you manage symbol visibility. There is such a thing as a “private” dependency. For example:
If LibA links with libZ statically, and doesn’t expose any internal libZ structures through its own APIs, then there’s absolutely no problem. Your code will never directly interact with the internal libZ of libA.
If LibZ is exposed by LibA, or LibA dynamically links with LibZ, then you have a problem. I’m not an expert on dynamic linkers, but they’re might be some platform specific workarounds you can do.
Something else I’ve seen before is some libraries use preprocessor macros for their namespaces. That way, you can change the namespace (and thus symbol names) at compile time. That way, you can have multiple copies of the same library coexisting, even with type safety at compile time.
Not sure how are you and @kibiz0r@midwest.social coming up with these concerns.
The only correct way to package such software is to vendor dependencies (packaged together or separately). And you can trivially change the sonames of vendored deps in your build scripts so that there are no conflicts whatsoever (I dual-package some stuff against an upstream and a fork and do just that). So dynamic vs. static is not the crux of the issue. The primary concerns are that distributors hate vendoring, irrespective of whether the vendored libs are linked in statically or dynamically. Distributors also hate potentially diverging forks maintained by random downstreams, which is what “patched dependencies” effectively are.
There is always room for some leeway of course, but that would depend on how relevant your software is, and/or whether a maintainer would want to take that burden on.
And finally, sometimes, such dependencies may provide added value that trumps all these concerns. So judging these things is always situational.
Bad form. Breaks SLSA some. Breaks some CVE tracking tools too.
If the patch introduces a vulnerabilty or breaking issue how would it be tracked?