eic-shell is the official installer and launcher of the EIC software environment (get.epic-eic.org redirects to it), but it has no license, no releases, no tests, and its only workflow deploys GitHub Pages, so changes to the scripts are not exercised before users download them from main. One human author made all commits in 24 months, no maintainers or owning group are documented, and the advertised -o/--organization option is not parsed. 91.7% of default-branch changes arrive through PRs under branch protection requiring one approval, and Dependabot updates the GitHub Actions.
Assessment by criterion
Code health & engineering practices 0.6
2
Established · confidence high
91.7% of first-parent commits in 12 months came from PRs and branch protection requires one approving review, but only 66.7% of merged PRs were reviewed by someone else, admins are exempt (PR #34 merged without review), and there is no CODEOWNERS.
Evidence (5)
Gaps to the next level
- Fewer than 90% of merged PRs are reviewed by someone other than the author.
- Branch protection does not apply to administrators; no CODEOWNERS file.
- Review expectations are not documented in the repository.
Actions
- medium S Enable "Do not allow bypassing the above settings" (enforce for admins) on
main and add .github/CODEOWNERS naming two reviewers for install.sh and install.py.
1
Continuous integration eng.ci
Initial · confidence high
The only workflow, deploy.yml, builds and deploys the GitHub Pages site on push to main; no workflow runs on pull requests and nothing executes install.sh or the generated launcher.
Evidence (3)
Gaps to the next level
- No PR-triggered workflow; the script served to users at get.epic-eic.org is never run in CI.
Actions
- medium S Add
.github/workflows/test.yml on pull_request and push that runs install.sh on ubuntu-latest and executes ./eic-shell -- eic-info, and make it a required status check.
0
Absent · confidence high
There are no test files or test framework; argument handling is untested, and -o/--organization is listed in both help texts but not parsed by either case statement.
Evidence (4)
Gaps to the next level
- No automated tests of
install.sh, the generated launchers, or install.py.
Actions
- high M Add
tests/ with bats tests for every install.sh and launcher option (including -o), the bind-path deduplication, and the generated eic-shell contents, run in CI.
0
Absent · confidence high
No shell or Python linter, formatter, or pre-commit configuration exists; install.py contains an undefined name (testing) that a linter would flag.
Evidence (3)
Gaps to the next level
- No shellcheck, shfmt, or ruff configured or enforced.
Actions
- high S Add
.pre-commit-config.yaml with shellcheck and ruff (as eic/containers does) and enable pre-commit.ci.
0
Architecture & language standards eng.modularity
Absent · confidence medium
The project is two loose scripts with no packaging: the 479-line install.sh embeds both launchers as heredocs, and it and install.py hard-code site paths (/gpfs02/eic/athena, /apps/singularity/3.7.1) and a legacy GitLab artifact URL with default version 3.0.1.
Evidence (4)
Gaps to the next level
- Launcher scripts are generated from heredocs inside
install.sh instead of separate template files. - Site-specific paths and a legacy download endpoint are hard-coded.
Actions
- high M Move the two launchers into template files (as proposed in PR
Documentation & usability 1.0
1
Initial · confidence medium
The README and the EIC tutorial give a working curl-based install and ./eic-shell quick start, but docker, wget and python3 (non-CVMFS fallback) are not named or versioned, most options are documented only in --help, and the CI section is marked as outdated.
Evidence (3)
Gaps to the next level
- Not all host dependencies are named with versions.
- Installer and launcher options are not documented in the README; the CI section and included-software list are stale.
Actions
- medium S Add a README "Requirements" section (bash, curl or wget, apptainer >= 1 or singularity >= 3, Docker version, CVMFS optional) and an "Options" section for
install.sh and eic-shell, and replace the outdated CI section with the eic/run-cvmfs-osg-eic-shell route.
1
Developer & API documentation doc.developer
Initial · confidence medium
install.sh and install.py carry inline comments and a module docstring, but there is no description of how the installer, generated launchers, install.py fallback and the Pages hosting fit together.
Evidence (3)
Gaps to the next level
- No architecture overview and no generated reference documentation.
Actions
- medium S Add
docs/architecture.md describing the install flow (CVMFS detection, image selection, launcher generation, --upgrade, get.epic-eic.org hosting) and publish it with the existing Pages workflow.
1
Initial · confidence low
Only the eic organization PR and issue templates apply; the repository has no CONTRIBUTING file describing how to test changes to the scripts or the PR process.
Evidence (3)
Gaps to the next level
- No
CONTRIBUTING.md covering local testing of install.sh, conventions, and the PR process.
Actions
- medium S Add
CONTRIBUTING.md describing how to test install.sh locally (with and without CVMFS, apptainer and docker), the shell conventions, and PR review expectations.
1
Initial · confidence medium
Median first response is 0.57 days, but half of the six issues opened in 12 months received no response and none is labeled, and three open PRs are older than 90 days.
Evidence (5)
Gaps to the next level
- New issues are not labeled or otherwise triaged;
Actions
- medium S Label all open issues with the existing label set, close
0
Absent · confidence high
One human author committed in 24 months; contributor PRs (#31, #39, #40) were closed or remain open, and no external PR was merged in 12 months.
Evidence (4)
Gaps to the next level
- Only one active author in 24 months.
Actions
- high S Review and merge the open contributor PR
1
Knowledge concentration (bus factor) com.bus-factor
Initial · confidence high
The top author wrote all non-bot commits in 24 months and is the only merger; one other person reviews.
Evidence (4)
git.top_author_share_24m = 1.0prs.distinct_reviewers_12m = 1prs.distinct_mergers_12m = 1files.codeowners = []
Gaps to the next level
- Bus factor (50%) is 1 and only one person merges.
- No CODEOWNERS or maintainer list.
Actions
- high S Add
.github/CODEOWNERS with two maintainers and have the second maintainer merge PRs.
0
Absent · confidence medium
Discussion happens in public issues (#33), but no README section, CODEOWNERS or governance file names the maintainers, the owning ePIC group, or a decision process; there are no milestones.
Evidence (3)
Gaps to the next level
- Maintainers and owning group are not identified in the repository.
Actions
- high S Add a README "Maintainers" section naming the maintainers and the owning ePIC computing group, and stating how changes to defaults (image, organization, CVMFS repository) are decided.
1
Code of conduct & user support com.conduct
Initial · confidence medium
The eic organization issue-template configuration links the ePIC Mattermost for questions, but no code of conduct applies to the repository or organization.
Evidence (2)
Gaps to the next level
- No code of conduct with a reporting contact.
Actions
- high S Link the ePIC collaboration code of conduct with its reporting contact from the README, or add
CODE_OF_CONDUCT.md.
Infrastructure & distribution 1.0
1
Initial · confidence medium
Installation is a documented curl | bash of install.sh from main (also at get.epic-eic.org), but there is no package recipe in eic-spack, Spack, conda-forge or PyPI.
Evidence (3)
Gaps to the next level
- No recipe in a domain package manager.
Actions
- medium S After tagging releases, add an
eic-shell package to eic-spack that installs install.sh at the released version.
0
Absent · confidence high
There are no tags or releases; users and eic-shell --upgrade fetch install.sh from main.
Evidence (3)
Gaps to the next level
- No versioned releases, version scheme, or release notes.
Actions
- high S Adopt CalVer or SemVer, tag a release with generated notes at least every six months, and record the installer version in the generated launcher.
The README states apptainer >= 1 or singularity >= 3, but docker, curl, wget and python3 are undeclared, and the non-CVMFS path runs install.py, which calls singularity pull and a legacy eicweb GitLab artifact URL.
Evidence (5)
Gaps to the next level
- Host tools are not all declared with minimum versions.
- The fallback download depends on the legacy
install.py and an eicweb GitLab artifact endpoint.
Actions
- medium S Check for and document every required host tool with a minimum version at the start of
install.sh, and replace the install.py fallback with a direct apptainer pull from the container registry.
2
Established · confidence medium
The launcher records organization, container and version and can select a tagged image (--version YY.MM.0-stable), but the installer itself is unversioned and --upgrade always takes main, and the default image is nightly.
Evidence (2)
Gaps to the next level
- The installer is not versioned, so the launcher that produced an environment cannot be recreated.
- No CI runs the installer in the environments it sets up.
Actions
- medium S Tag installer releases and let
--upgrade and get.epic-eic.org resolve to the latest tag, writing the installer version into the generated eic-shell.
1
Portability & heterogeneous computing dist.portability
Initial · confidence medium
The installer targets Linux (apptainer) and macOS (docker) but no platform is tested in CI, Linux aarch64 is not detected (it checks for arm64, which Linux reports as aarch64), and site-specific fallback paths remain.
Evidence (4)
Gaps to the next level
- No CI on any platform.
- Linux aarch64 detection does not match
uname -m output; macOS arm64 always runs amd64 images under emulation.
Actions
- medium S Add a CI matrix of
ubuntu-latest (apptainer) and ubuntu-24.04-arm (docker) that runs the installer, and match aarch64 as well as arm64 in the OS detection.
EIC ecosystem integration 2.0
3
Reuse of EIC-supported components eic.reuse
Sustained · confidence medium
The project needs no domain functionality and has no parallel implementations, and it is the component other EIC software reuses to install the environment (eic/containers delegates its install.sh to it; eic/snippets batch scripts call it).
Evidence (2)
Data formats & interoperability eic.data-model
Not applicable · confidence high
Not applicable: The project is an installer and launcher and reads or writes no physics or detector data.
Not applicable: the scripts only download container images and generate a launcher script.
1
Initial · confidence medium
Launching eic-shell images is the documented purpose of the project, but no CI job runs the installer or launcher against an eic container image.
Evidence (3)
Gaps to the next level
- Compatibility with current eic_xl images is not tested in CI.
Actions
- medium S Add a CI job that mounts CVMFS (
cvmfs-contrib/github-action-cvmfs), installs with -v nightly and with a pinned stable tag, and runs ./eic-shell -- eic-info.
2
Currency with the EIC stack eic.currency
Established · confidence medium
The installer defaults to the current eicweb/eic_xl:nightly image on CVMFS or Docker Hub and the tutorial uses it, but ATHENA-era singularity 2.x, /gpfs02/eic/athena and GitLab-artifact code paths remain, and the CVMFS repository question in #30 is open.
Evidence (3)
Gaps to the next level
- Deprecated singularity 2.x and legacy image-location code paths are still in use.
Actions
- low S Remove the singularity 2.x
.simg branch and the legacy /cvmfs/eic.opensciencegrid.org/singularity/athena and /gpfs02 lookups, and decide
Impact & long-term viability 0.8
0
Absent · confidence high
The repository has no LICENSE file and GitHub detects no license.
Evidence (2)
repo.license_spdx = nullfiles.license = []
Gaps to the next level
- No license; the scripts are all rights reserved.
Actions
- high S Add a
LICENSE file with an OSI-approved license (for example MIT or LGPL-3.0-or-later) agreed by the contributors.
0
Absent · confidence high
There is no CITATION.cff, Zenodo DOI, codemeta or author list beyond a docstring in install.py.
Evidence (3)
files.citation_cff = []files.zenodo_json = []files.authors = []
Gaps to the next level
- No citation information or maintained contributor list.
Actions
- high S Add
CITATION.cff listing all contributors and enable the Zenodo-GitHub integration.
3
Adoption & downstream use via.adoption
Sustained · confidence medium
get.epic-eic.org redirects to this installer, which the EIC tutorial and EICrecon documentation prescribe, EIC batch production scripts call it, and an analysis of the SoLID experiment outside EIC uses it.
Evidence (4)
Institutional backing & continuity via.support
Absent · confidence low
The repository names no current maintainers, affiliations, owning ePIC group or funding; the only named authors are in the install.py docstring (added 2021) and no longer commit.
Evidence (2)
Gaps to the next level
- No identifiable current maintainers or institutional backing.
Actions
- high S State in the README the ePIC computing group responsible for eic-shell and the maintainers' institutions.