fix: bump im-data-manager-job-utilities to 1.3.0 - #22
Merged
Conversation
im-rdkit-utilities==1.0.0 hard-pins im-data-manager-job-utilities==1.3.0, which conflicted with these Dockerfiles' older pins (1.1.1/1.0.1) and broke the build entirely (ResolutionImpossible) - not caught in #21 because the images weren't rebuilt locally at review time. Verified: mordred, moldb and oddt images now build and pass their jote suites end-to-end (mordred: 2/2, moldb's non-nextflow jobs, plus a direct check of updateChargeFlagInAtomBlock). prep's image build is separately blocked by an unrelated, pre-existing issue: its apt-get step pulls packages from bullseye-security that have since been pruned from the Debian mirror - confirmed this also fails identically on the pre-migration Dockerfile-prep, so it's not something this change introduced. Verified prep's pip resolution (the part this change actually touches) succeeds cleanly in isolation. Part of #18. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2 tasks
tdudgeon
added a commit
that referenced
this pull request
Aug 5, 2026
Dockerfile-prep never ran apt-get update itself, relying on the package index baked into informaticsmatters/vs-rdkit-base:latest at base-image build time. Since bullseye-security periodically prunes superseded point-release .debs, that stale index eventually points at files that no longer exist, and the build starts failing with 404s - this is what was blocking jote for open3dalign, sucos, assemble_conformers, cluster_butina, enumerate, le_conformers, rdkit_dedup, rdkit_props, sa_score, screen and reactor after #21/#22. No version is pinned for openbabel here, so a fresh apt-get update resolves to whatever build is currently on the mirror instead (still 3.1.1, just a different point release). Verified: image builds; full im-virtual-screening/rdkit/xchem jote suite passes 32/32 (with NXF_VER=22.10.0 per docs/testing-jobs.md, for the nextflow-based jobs in the same suite). Part of #18. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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
1 participant
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
Follow-up to #21.
im-rdkit-utilities==1.0.0hard-pinsim-data-manager-job-utilities==1.3.0, which conflicted with these Dockerfiles' older pins (1.1.1/1.0.1) and broke the build entirely (ResolutionImpossible) — not caught in #21 because the images weren't rebuilt locally at review time.Test plan
Dockerfile-mordred,Dockerfile-moldb,Dockerfile-oddtall build cleanly nowjotepasses for the mordred collection (2/2) and moldb's non-nextflow jobsrdkit_utils.updateChargeFlagInAtomBlock(used bymoldb/enumerate.py/moldb/filter.py) still produces correct outputDockerfile-prep's build is separately blocked by an unrelated, pre-existing issue: itsapt-get install openbabel python3-openbabelstep pulls frombullseye-security, which has since pruned those package builds from the mirror. Confirmed this also fails identically checking out the pre-migrationDockerfile-prep— not something this change introduced. Verified prep's pip resolution (the part this PR actually touches) succeeds cleanly in isolation. Flagging since I couldn't get a full jote run for the prep-based jobs (open3dalign,sucos,assemble_conformers,cluster_butina,enumerate,le_conformers,rdkit_dedup,rdkit_props,screen,reactor) as a result.Part of #18.
🤖 Generated with Claude Code