Library dependencies refer to the relationship that exists between different libraries or packages used in a program.
When a module A depends on another module B, it means that module A uses module B (therefore, module A needs module B to function).
In principle, including a dependency between libraries is not a bad thing. It happens every day, and it would be almost impossible to create a program without breaking it down into modules.
However, it also has its downsides. If we do not manage dependencies properly, your program can turn into hell 🔥🔥🔥.
Why are we making an entry just to explain dependencies? In reality, it is something quite simple to understand.
Because it is one of the biggest problems you will face in development. It has always been this way (and I don’t think it will change). So it deserves that we take a pause and talk about it
Let’s look at a simple example
Let’s see it with a very simplified example with only four dependencies. But keep in mind that in a normal project, it is common to have hundreds of dependencies.
Initial situation, “my application”
Suppose you are making your application called “my application”. Among many things, your application manages Notes and Attachments.
To do this, you or a coworker have made two libraries “Notes Library” and “Attachments Library”.
These in turn depend on two other libraries with useful functions to manage Texts and Dates. Let’s assume they are Open Source and maintained by the community.
So far, we are doing great! Perfect!
Update 1
Now, suppose the “Text Utilities” library is updated to v2.0. Great! It surely has some very interesting and useful functions. Functions that you might not even need at all… but hey, they are there.
So this means you should update your “Notes Library” and your application to v2.0.
Update 2
Some time passes, and the “Date Utilities” library is updated to v2.0. This is even worse because both “Notes Library” and “Attachments Library” depend on it.
So you have to update both, and with them your application. Which poor thing is already at version v3.0… or worse, at v4.0, if your libraries haven’t been updated at the same time.
The problem of dependencies
I think the problem is already clear. Every time a dependency is updated, the entire “chain” of libraries that connects to your application must also increase in version (which is damn horrible).
Of course, you might say “well, I won’t update, I’ll stick with the old version”. Sure, but how long will it take until one of the libraries you use, which also uses that library, gets updated? And then you will be indirectly using two different versions, and surely… kaboom! 💥
With “this” depending on “that” and “the other” on “the other thing,” it easily gets messy 🐔. In the end, if you do not manage dependencies correctly, you can end up with a huge problem.
Remember that the example we saw was very simple with only four dependencies, at two levels. But in a project, you could easily end up with hundreds or thousands of dependencies and dozens of levels.
Dependencies are evil
So what do we do? Do we avoid dependencies between libraries? No, it’s not that simple. In fact, I have already said that it is practically impossible to create a program without having dependencies.
But what you should always keep in mind is that:
- The fewer dependencies the better
- You must keep them controlled
- When it comes to updating, it can be a headache to manage
To avoid these problems, many tools have been created. Some of which are package managers, versioning systems, and even source code control.