AI and Automation on IBM Z

AI and Automation on IBM Z

AI and Automation on IBM Z

AI and Automation on IBM Z is a one-stop destination to find the latest communications, news, videos and events, as well as collaborate and network.


#DevOps
#IBMZOS
#IBMZ
#DevOpsSolutions
#GenerativeAI

 View Only

Development Shells as Code: Nix Shells and Direnv for z/OS Development

By John Craig posted 26 days ago

  

Introduction

Over the past few months, IBM has absorbed a considerable number of both interns and new hires. It is always exciting to see what progress can be made with this wealth of team members, but one obstacle always lies in the way of productivity: workstation setup.

While there are plenty of time-consuming steps to the typical onboarding process, getting a new team member set up with the same toolchains used by the rest of their team is a particularly challenging one. This is because development environments are often unique to each team, and documentation of them is not always a priority.

But what if this didn't have to be the case? What if setup instructions for development environments didn't need to be recorded at all, because all the details needed to create them were stored directly alongside the code they were needed to work with?

Nix Dev Shells

Nix is often associated with package management and operating system configuration, but one of its most immediately useful features for developers is the concept of a development shell. A development shell is a declarative description of the tools, dependencies, and environment variables required to work on a project. Rather than manually installing software and hoping that everyone's workstation ends up looking roughly the same, teams can define exactly what is needed in a configuration file stored directly in the repository.

For a z/OS development team, this can include everything that lives on the local workstation: Git tooling, Zowe CLI, Python, Node.js, Java SDKs, language servers, documentation generators, testing utilities, and more. Although the code itself may ultimately be built, deployed, or executed on a remote z/OS system, developers still rely on a substantial collection of local tools every day.

The real benefit is consistency. When a new team member clones a repository, they no longer need to follow a lengthy setup guide or track down the "correct" versions of a dozen utilities. The project itself defines the environment. If the required toolchain changes, the configuration changes alongside it, and every developer receives the update automatically. The environment becomes version-controlled just like the source code.

This also makes it much easier to move between projects. A developer contributing to multiple repositories can have completely different toolchains for each one without worrying about conflicting installations or modifying their global workstation configuration.

direnv

While Nix dev shells solve the problem of defining a development environment, there is still the question of how developers enter that environment. This is where direnv comes in.

direnv is a lightweight utility that watches the current directory and automatically loads environment settings whenever you enter a project. When paired with a Nix dev shell, this means that simply changing into a repository directory is enough to activate the correct toolchain. No additional commands are required, and leaving the directory automatically restores your previous environment.

The result is a workflow that feels surprisingly natural. Instead of remembering which setup script to run or which environment to activate, developers simply navigate to the project they want to work on. The appropriate versions of all required tools become available automatically.

For teams, this removes a significant source of confusion. How many times has someone reported an issue only to discover they were using the wrong version of a CLI, SDK, or scripting language? By coupling the environment directly to the repository, the chances of these problems occurring are dramatically reduced.

Perhaps most importantly, this approach works just as well for z/OS developers as it does for teams targeting Linux or cloud-native platforms. Nix does not need to run on the remote z/OS system to provide value. Instead, it standardizes the workstation environment used to interact with that system, ensuring that every developer has a consistent and reproducible set of local tools.

In short, Nix and direnv are helping us tame everything around mainframe development. The less time we spend configuring workstations, troubleshooting missing dependencies, and maintaining setup documentation, the more time we can spend actually developing software.
0 comments
10 views

Permalink