>> Check for conflicts of this version of this library with other software currently in use (by other developers maybe, or even by the same developer).
> That's not the case when using containers properly. Every service gets it's own environment so whatever version of lib-xyz is needed, even if incompatible with other parts of the project, are walled off for only the service that needs it.
This illustrates why developers should have some experience with administering
systems: do not deploy unrelated services on the same machine.
And you know what happens as a byproduct of this rule of hygiene? Suddenly
the version conflicts disappear, at least for things that aren't broken
anyway.
> That's not the case when using containers properly. Every service gets it's own environment so whatever version of lib-xyz is needed, even if incompatible with other parts of the project, are walled off for only the service that needs it.
This illustrates why developers should have some experience with administering systems: do not deploy unrelated services on the same machine.
And you know what happens as a byproduct of this rule of hygiene? Suddenly the version conflicts disappear, at least for things that aren't broken anyway.