RosettaCommons
Question: RFpeptides Branch - Should I clone the branch directly or merge with main for containerization?
Hi team!
I'm looking to build RFpeptides container and noticed that the rfpeptides branch is currently 5 commits ahead and 13 commits behind the main branch. This creates some uncertainty about the best approach for deployment.
Current situation:
- The rfpeptides branch contains RFpeptides-specific functionality not present in main
- The main branch has 13 newer commits with bug fixes and improvements (including recent chain/residue numbering fixes in #398
- Both branches have diverged since commit b44206a
My questions:
- For RFpeptides usage: Should I clone the rfpeptides branch directly, or is there a recommended way to merge it with main to get both the RFpeptides functionality AND the latest bug fixes?
- Containerization: Can I safely use the existing docker/Dockerfile with the rfpeptides branch, or are there any RFpeptides-specific container requirements?
- Branch status: Is the rfpeptides branch actively maintained? Are there plans to merge it into main or keep it as a separate feature branch?
- Compatibility: Are there any known conflicts between the RFpeptides changes and the recent improvements in main?
Any guidance on the recommended deployment strategy would be greatly appreciated!
Thanks!
Following up on my earlier question about branch synchronization, I've analyzed the code differences and have a specific question about merge direction.
Current Analysis:
- After examining the changes, I found that:
The rfpeptides branch has simplified chain handling:
self.chain_idx = ['A' if i < self.binderlen else 'B' for i in range(L_mapped)]
The main branch has sophisticated chain/residue numbering preservation from PR #348, supporting 52+ chain IDs and maintaining original PDB numbering.
The Question: Which merge direction preserves the most functionality?
- Option A: main ← rfpeptides
- Option B: rfpeptides ← main
My specific questions:
- Is the simplified chain handling in rfpeptides intentional for RFpeptides-specific use cases, or was it just developed before the main branch improvements?
- Would merging main's advanced chain handling into rfpeptides break RFpeptides functionality, or would it enhance it?
- What's the intended relationship, should rfpeptides be a long-term separate branch, or eventually merged back to main?
@BiologyGeek , I can't answer all of your questions, but I wrote #348 . I didn't specifically consider the rfpeptides workflow at that time, and I'm not sure what the intention would be for support of rfpeptides going forward. I would say that if the assumption that rfpeptides is going to have a single protein chain and a single peptide chain, and that the protein chain will be renumbered, that could be potentially difficult for the same reason that those assumptions were problematic for regular rfdiffusion. I would assume a multi-chain peptide would be unusual, but certainly being able to design a peptide to a protein with multiple chains seems like useful functionality. But I think the rfpeptide developers would need to answer your specific questions about their intentions.
@BiologyGeek, From looking at the RFpeptides branch, those 5 commits seem to be the same as the the 5 commits of the PR that was merged for the RFpeptide macrocyclic peptide design #357. I'm not sure why it shows that the rfpeptides branch is 5 commits ahead of main. My advice would be to stick with main.
If you do run into bugs using the main branch for designing peptides please open another issue!
