Repository navigation
chore(syncweaver): update from CCBR/MOSuite@v0.4.2 - #9
Conversation
Pass the input multiOmicDataSet directly to MOSuite, expose strict DEG threshold controls, and support optional comma-separated contrast subsets. _AI assistance: GitHub Copilot_.
_AI assistance: GitHub Copilot_.
_AI assistance: GitHub Copilot_.
|
I don't feel I have enough understanding of Syncweaver to review this PR. But, I'd love to learn so I can help in the future. |
| "repo_url": "https://github.com/CCBR/MOSuite", | ||
| "ref": "v0.4.1", | ||
| "git_sha": "4e85d49ab155618d9f6beafd327b6fb87dfa8609" | ||
| "ref": "v0.4.2", |
There was a problem hiding this comment.
@TJoshMeyer this is the most important part of the PR. Syncweaver opened up this PR because a new version of MOSuite was released (v0.4.2), so it updated the lock file here and included the new version of the package in code/.
There was a problem hiding this comment.
Ohhhh! I think I understand ...
The capsule basically maintains a copy of the entire package, and this "lock file" is that copy? So, when the main package gets updated, because you merge my or someone else's PR, then Syncweaver has to distribute the newly-updated copy of MOSuite to all the MOSuite packages, to make sure they have the latest.
Is that approximately what's going on here?
There was a problem hiding this comment.
Yep that's right! the lockfile documents the version of MOSuite that is kept in this repo. normally this is not necessary (usually dependencies are just installed in a container and loaded with library), but we wanted to help streamline development in case an analyst/dev needs to update code in MOSuite directly in the capsule for a tight deadline.
There was a problem hiding this comment.
Very cool and makes sense, now I see it in action! I was honestly not picking up on the Syncweaver discussions in meetings prior to this. Thanks for the insights!
I think this also explains some other things I was running into trying certain changes in my PRs but finding I'd need to change a like a LOT of files. I think I was getting "ahead of syncweaver" sometimes, changing the package and a capsule around the same time in linked PRs. Most of the time it was no issue, but doing some Venn stuff today, I noticed that CoPilot was editing like 25 files in my feature branch, far more than I was intending to edit on this PR, which was scoped rather succinctly. I dug around a bit and convinced myself that my draft Venn capsule PR #10 was basically trying to update the internal locked copy of MOSuite in the capsule to have the changes that were already pending in that Venn capsule Syncweaver PR #9.
Anyways, I'll be let things go their natural course and circle back to #10 once I see #9 merged. Thanks for always being generous with your knowledge, @kelly-sovacool !
|
@TJoshMeyer looks like you accidentally had this branch selected when you were making changes to the venn diagram code (those edits belong in #10). I'll revert them so this PR is a clean update from syncweaver without any other changes to the capsule. Reverted with |
Automated source update orchestrated by
NIDAP-Community/syncweaver-orchestrator.Inputs used
CCBR/MOSuite.syncweaver-lock.jsonv0.4.2Updated source paths
code/MOSuite