Dependency hell is a negative
situation that occurs when a software application is not able to access the
additional programming it requires in order to work. In software development,
additional programs that software requires are called dependencies. Sometimes
known as JAR hell or class-path hell, dependency hell's common outcomes include
software performing abnormally, bugs, errors messages when trying to run or
install software, or the software ceasing to function. Many times, these
software dependencies are developed by third parties.
The cause of dependency hell is varied,
but it usually happens for one of four reasons:
1. The main software relies on a multitude
of large software libraries, causing lengthy downloads and decreasing the
portability of the software. Even if an application requires only a small
portion of a large library, the whole library must be downloaded.
2. The main software creates a chain of
dependencies, where the software relies on product A, but A relies on product B
to function, and B needs product C to work properly.
3. Conflicting programs that require
different versions of software or libraries to work. Application X requires
software FF version 2.0 to work, while application Y requires software FF
version 2.5 to work, and both versions of FF cannot be installed at the same
time.
4. The software's requirements create
circular dependencies. Application Y version 3.1 requires software EE. Software
EE requires application W to work. Application W depends on software HH. And
software HH relies on Application Y version 2.6.
These dependencies can be a major
headache for users and software creators alike, hence
the hell designation.
However, package managers and automated testing have incorporated
dependency
checking tools to alleviate some of these dependency hells.
Advanced application
development and deployment environments such immutable
infrastructures are a
great means of avoiding these kinds of dependency problems and
uncontrolled
change. The IT team can package and deploy an app in a self-contained
manner.
When a change is made, the entire image is recreated and redeployed, not
patched
in-place.
Comments
Post a Comment