Defer spython imports in singularity.py to where they're used - #2344
Merged
mr-c merged 1 commit intoAug 28, 2026
Merged
Conversation
spython was imported at module level, meaning merely importing cwltool.singularity (which cwltool.workflow/command_line_tool do unconditionally) required spython to be installed even when Singularity support is never used, e.g. for `cwltool --validate`. spython itself is only used inside SingularityCommandLineJob.get_image's Dockerfile-build branch, so move the three imports there. No behavior change for actual Singularity usage.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2344 +/- ##
=======================================
Coverage 85.24% 85.24%
=======================================
Files 46 46
Lines 8622 8622
Branches 2020 2020
=======================================
Hits 7350 7350
Misses 806 806
Partials 466 466 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
mr-c
approved these changes
Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
cwltool/singularity.pyimportsspython.main.Client,spython.main.parse.parsers.docker.DockerParser, andspython.main.parse.writers.singularity.SingularityWriterat module level. Sincecwltool.workflow/cwltool.command_line_toolimportcwltool.singularityunconditionally, this meansspython(MPL-2.0 licensed) must be installed just to import cwltool at all — even for use cases likecwltool --validatethat never touch Singularity.All three names are only actually used inside
SingularityCommandLineJob.get_image's Dockerfile-build branch (building a Singularity image from adockerFilerequirement), never at import time. This PR moves the three imports into that branch, right before first use.No behavior change for actual Singularity usage — the imports still happen, just lazily, the first time an image actually needs to be built from a Dockerfile.
Verification
flake8,black --check, andmypyall pass on the changed file (mypy reports 3 pre-existing, unrelated errors incwlviewer.pythat exist identically onmainbefore this change).pytest tests/test_singularity.py tests/test_singularity_versions.pyand the broader-k "singularity or docker"slice: all pass (remaining skips are pre-existing environment gates — no Docker/Singularity/Podman binary available — unrelated to this change).import cwltool.singularitynow succeeds withspythoncompletely uninstalled, andcwltool --validateruns successfully end-to-end withoutspythoninstalled.Motivation
We ran into this while trying to depend on cwltool from an internal Apache-2.0-licensed project that only needs
--validate-style validation. Being forced to pull in an MPL-2.0-licensed package for a feature we never use blocked our internal third-party license review. This is a minimal, behavior-preserving fix rather than a request to change cwltool's own dependency policy — happy to adjust the approach if maintainers prefer something different (e.g. a try/except ImportError guard instead of a bare deferred import).