The problem with DRY is that programmers learn that it's a good thing but don't learn when not to apply it. There are very good reasons to repeat yourself. The mantra I learned, which has served me quite well, is: Optimize for less state, less coupling, less complexity and less code...in that order.
I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.
I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.
Curious where "Optimize for less state, less coupling, less complexity and less code...in that order." came from. Would like to read more from that source.
On the other hand I learned not to be too dogmatic about DRY because it becomes costly especially in distributed systems where additional dependencies introduced for reusability sake complicate build process and deployment.
Sometimes it's better to copy&paste instead of coupling components.
Separating the library does not remove dependency because library version change affects both primary components so the change requires coordination. This is really fundamental in large systems and I was hit by it many times.
Copy & paste sounds bad but what it really says is: let's make that piece an invariant and don't import the library if you only need one short function.
So I would say the trade off boils down to "simplicity vs flexibility"
> library version change affects both primary components
In my experience, it changes neither, because the interface of the library just doesn't change. Of course it depends where you make the separation. Basically, if the interface to your library is big, you either suck at API design, or you traced the wrong boundary.
Now if you happen to only need a small fraction of a sizeable library, I can only suspect the library itself fell prey to scope creep. If there's no way to import what you need, and little more, that probably indicates a problem with the library itself.
Even big libraries which by nature must make many different things can often be separated into different components. Like the SDL for instance.
---
Oh, and I was assuming we were talking about internal dependencies. Like, you write the library which will then be used in different parts of your (possibly big) project. That's very different from external dependencies, which are generally bigger, harder to freeze and harder to update.
If your build process and deployment are forcing you to decomponentize something so you have to copy and paste it, I'd blame those processes instead of saying there's an inherent shortcoming in the idea of composing components.
I've learned to happily repeat code if it means making my programs/components more stateless, more decoupled or simpler to understand. There's nothing worse than trying to make sense of code where a programmer tried to shoehorn two similar but ultimately different concerns through the same code paths.
I'll also happily add complexity if it means reducing coupling and state and add coupling if it means being stateless. State is the ultimate enemy that makes code inflexible and buggy, especially when it's mutable state.