Table of contents
Dependency Management
As you can see in the title there is a word called Dependency Management.
So what does that mean?
Dependency management is a crucial concept in software development that refers to the process of handling and organizing the various external libraries, modules, frameworks, and packages that a software project relies on to function correctly. In modern software development, projects are seldom built entirely from scratch, and developers often leverage existing code components or libraries to save time and effort.
Some popular dependency management tools include npm (Node Package Manager) for JavaScript/Node.js projects, pip for Python projects, and Maven for Java projects.
So, basically where your software depends on another software. Like you can see in below image.
To understand this, let us imagine that you are hosting a dinner party and your guests are your software dependency, they need to play nicely together, but some of them have very specific needs, one guest let's call him Python2.7 refuses to sit near Python3. Another guest TensorFlow insists on bringing along an old friend Cuda10, even though your house is already renovated for Cuda11.
If you are working on a project, and also multiple developers are also working on it. You need to mention the Readme.md file for that project with specific instructions like how to install, to run which command, what version of packages/modules are required to run etc.
Firstly, if you tried to set up Open Source Projects or your new company's project repository you will feel the pain. You will relate to it. Secondly, if you are a software engineer, you tend to work on multiple projects with multiple codebases if each of them has different dependencies, your life becomes very difficult. The reason is a dependency can only be a required by specific project, you don't have to be available system-wide, but you want your environment to be shareable with another developer in your team.
You might think that ASDF might solve it.
Refer documentation you will understand it more clearly.
Well, you are partially correct..!! Basically, in your projects root folder .tool_versions file. That file defines the version of language runtime.
So whenever ASDF goes to that file, it will load the languages with a specific version, which definitely sounds good.
But there are a few problems with it.
Languages require dependencies to build.
Example: erlang requires ncurses, OpenSSL etc.
If your project depends on a tool, say ffmpeg or fwup. Again installing needs to care manually.
Needs to install the plugin manually.
What if...
We could have dependencies per folder
Not just language runtime dependencies, but each and everything. Including GCC, Clang, anything!
We could have the same reproducible env for each developer no matter what things are installed on their system.
We didn't have to spend a week just setting up our system for a project.
Here is where nix comes into the picture.
Nix refers to a lot of things. It is a purely functional package manager. But now it is more than that. Like Nix a programming language.
Below in the image, We are in the project1 directory, let us do python --version.
But at the same time we go to another directory, let us do python --version.
Python version is particular isolated for each project. If we go for, home directory, we will check python version. It is like that
So like, this is the ideal workflow of the project.
Basic Terminology
Derivations: A derivation in Nix is a definition of a build, which takes some inputs and produces an output (packages)
Nix Shell*:* Temporary environment where build inputs of a derivation are available to the user.
- By default,
shell.nixfile is used to find the definition of the derivations.
- By default,
direnv : It automatically set up your Nix environment with the required packages and dependencies specific to a project.
- When you leave the project directory, direnv unloads those environment settings, ensuring that your system returns to its previous state.
niv : Package sets are collections of packages with specific versions that are known to work together.
They are often used in Nix projects to provide a consistent and tested set of dependencies.
However, package sets can be subject to changes, and updates to the package set might introduce new versions of packages or change existing ones.
This can lead to different behavior and results when rebuilding projects over time.
Conclusion
Nix plays a crucial role in modern development environments due to its unique and powerful features. By providing a declarative approach to package management, Nix ensures consistency and reproducibility across different systems, making it easier to share and distribute projects. Its functional package model enables sandboxed environments, allowing developers to experiment and work confidently without worrying about dependency conflicts. Moreover, Nix's built-in rollback capability ensures the ability to revert changes effortlessly, safeguarding against unexpected issues. As the development landscape continues to evolve, Nix stands as a reliable tool, empowering developers to build robust, scalable, and efficient software applications for the future. Embracing Nix offers a path to more streamlined and reliable development processes, ultimately leading to better software and enhanced collaboration among teams.