Documenting Software Dependencies for Published Research

Modern research increasingly depends on software. Statistical packages process datasets, programming libraries implement analytical methods, simulation platforms model complex systems, and specialized tools transform raw observations into publishable findings. Yet software is often treated as a minor methodological detail rather than as part of the research record.

A statement such as “the analysis was conducted using Python,” “the data were analyzed in R,” or “regressions were performed in Stata” may identify the primary tool, but it rarely provides enough information for another researcher to reproduce the computational environment. The underlying analysis may depend on dozens of packages, libraries, extensions, operating-system components, external tools, and specific software versions.

This distinction matters because reproducibility requires more than access to the final manuscript or source code. Researchers need to know which computational environment produced the reported results and how that environment can be reconstructed. Established reproducibility guidance similarly emphasizes documenting methodology, data, code, software dependencies, and the computational environment.

The Hidden Dependency Problem

Research software rarely operates in isolation. A researcher may write a Python script that depends on NumPy, pandas, SciPy, and a particular machine-learning framework. A statistical analysis conducted in R may depend on dozens of packages, each with its own dependencies. A computational model may require a specific compiler, operating system, database, GPU library, or external application.

These dependencies create a computational chain:

Research question → Data → Code → Software → Libraries → Dependencies → Operating environment → Results

If one important component changes, the final output can also change.

Software libraries evolve continuously. Functions may be deprecated, algorithms may be modified, default parameters may change, and compatibility requirements may be updated. Consequently, code that worked perfectly when a study was conducted may produce errors—or even different results—when executed several years later.

What Should Researchers Document?

Effective documentation does not mean creating an enormous technical inventory that readers cannot understand. Instead, researchers should identify the components that materially affect the analysis and provide enough information for another researcher to reconstruct the environment.

1. Primary Software

Begin by identifying the main software used for analysis. For each major tool, record:

• Software name
• Version or release number
• Developer or organization
• Operating system
• Relevant edition or configuration
• Major modules or extensions used

2. Packages and Libraries

The next layer is often overlooked. Researchers should identify packages or libraries that directly contributed to data processing, statistical estimation, visualization, modelling, or other computational procedures. A useful dependency record might include:

Package | Version | Purpose | Source

This allows future researchers to distinguish between essential dependencies and incidental software installed on the researcher’s computer.

3. Operating System and Hardware

The computational environment can extend beyond software. Where relevant, researchers should document the operating system and major hardware characteristics, particularly when computation depends on GPUs, specialized processors, memory capacity, or parallel processing.

For example:

Operating system: Ubuntu 24.04
Processor: specified CPU architecture
GPU: specified model, where relevant
Programming environment: specified version

Not every paper requires a detailed hardware inventory. The level of documentation should correspond to the extent to which the environment could influence execution or results.

Version Numbers Are Essential

One of the most common weaknesses in software reporting is the omission of version numbers.A software name identifies a tool; a version identifies the computational state of that tool at a particular point in time.

This becomes especially important when software changes rapidly. Two researchers can execute apparently identical code using different versions of a library and obtain different outputs because of changes in algorithms, numerical routines, dependencies, or default settings.

Use Machine-Readable Dependency Files

Manual documentation is valuable, but automated approaches can make dependency preservation substantially more reliable. Researchers using programming environments should consider generating machine-readable dependency specifications whenever possible. Examples include environment or package-lock files that record the exact versions required by a project.

Containers and Virtual Environments

For computationally intensive or highly dependent research, virtual environments and containers can provide an additional layer of protection against software drift. Instead of asking future researchers to install every component manually, a researcher can preserve an environment that specifies the required software stack.

Containers are particularly useful when:

• multiple software dependencies interact;
• installation is complicated;
• operating-system differences create compatibility problems;
• analyses need to be rerun repeatedly;
• the research is expected to remain useful for many years.

Connect Software to the Research Workflow

Dependency documentation becomes more valuable when it is connected to individual analytical steps. Instead of providing one long list of software, researchers can explain which dependency was used for which task.

For example:

Data preparation → pandas
Statistical estimation → statsmodels
Machine learning → scikit-learn
Visualization → matplotlib

Cite Software as a Research Output

Software deserves appropriate scholarly recognition.

When researchers use scientific software, they should consult the software developer’s recommended citation method and cite the relevant software publication, repository, or persistent identifier where available. Software citation supports both attribution and discovery, while helping researchers identify exactly which computational resource contributed to a study.

A Practical Minimum Standard for Authors

Before submitting a computational research paper, authors can ask five questions:

Can another researcher identify exactly what software we used?

Can they determine which versions were used?

Can they identify the important libraries and dependencies?

Can they access the code and relevant computational environment?

Can they understand how the environment connects to the reported analysis?

If the answer to each question is yes, the research is substantially better positioned for verification and reuse.

A practical software statement might therefore contain four components:

Software: Name and version
Dependencies: Major packages/libraries and versions
Environment: Operating system and relevant computational requirements
Access: Repository, archived release, DOI, or supplementary artefact

From Reproducibility to Research Longevity

The importance of dependency documentation extends beyond reproducing one paper. Well-documented computational environments make research easier to audit, teach, reuse, extend, and build upon. They also reduce the risk that valuable research becomes inaccessible because a particular software configuration disappears.

This is especially relevant to open-access publishing. CLS emphasizes open scholarly communication, reproducibility, software and code availability, and long-term preservation of published research. Its author guidance recommends depositing data and code in trusted repositories where possible, while its archiving policy emphasizes continued accessibility of published content.