Dependencies between libraries refer to the relationship that exists between different libraries or packages used in a program.
When module A depends on another module B, it means that module A uses module B. Or in other words, module A needs module B to function.
In principle, including a dependency between libraries is not a bad thing. It is done every day, and it would be almost impossible to create a program without dividing it into modules.
However, it also has its negative side. If we do not manage dependencies correctly, your program can become a hellfire 🔥🔥🔥.
Why do we make an entry just to explain dependencies? It’s actually quite simple to understand.
Because it is one of the biggest problems you will have in development. It has always been like this, and I don’t think it’s going to be fixed. So it deserves that we take a break and talk about it.
Let’s see a simple example
Let’s take a look at it with a very simplified example with only four dependencies. But keep in mind that in a normal project, it is normal to have hundreds of dependencies.
Initial situation, “my application”
Let’s say you are making your application called “my application”. Among many things, your application manages Notes and Attachments.
For 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, so good. Perfect!
Now, let’s assume that the “Text utilities” library is updated to v2.0. Great! Surely it has very interesting and useful functions. Functions that you may not even need at all… but hey, there they are.
So this means that you should update your “Notes library” and your application to v2.0.
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 your application. Which is now in version v3.0. Or even v4.0, if your libraries have not been updated.
The problem with dependencies
I think the problem is already evident. Every time a dependency is updated, the whole “chain” of libraries that make up your application must increase in version. Which is freaking horrible.
Of course, you could say “well, I don’t update, I’ll stick with the old version”. Yeah, but how long will it be until another library that you depend on does get updated? And then… bam! 💥
Remember that this is a very simple example with only four dependencies, in two levels. But in a project, you could easily go to hundreds or thousands of dependencies and dozens of levels.
With this depending on that, that also depending on this, it’s a freaking mess! In the end, if you don’t manage dependencies, you can end up with a huge problem.
Dependencies are evil
So what do we do. Do we avoid dependencies between libraries? No, it’s not that either. In fact, I have already said that it is practically impossible to make a program without having dependencies.
But what you do have to always keep in mind is that:
- The fewer dependencies, the better
- You must have them under control
- When updating, it can be a headache
To avoid these problems, many tools have been created. Some of which are package managers, versioning systems, and even source code control.