C-F migration | Short term JRG – Current state of omnia branches: Normal omnia: Uses infra from before conda-forge was a thing. Conda-build 3 was backwards-compatible with conda-build 2, so we never updates. Updated omnia: We made omnia-dev use azure and conda-build 3. This builds nightlies for openmm. I stopped on the omnia-dev → omnia migration (PR #1010) when it seemed like we could get onto conda-forge. There are previous recipes that will fail because of syntax differences. We will need to do a lot of pruning. Conclusion: One option: PR #1010: We might be able to update omnia to CB3, but it will require all of our time to update recipes. But I can’t guarantee this will be simple. Could have 1010 remain on branch, and do all new builds there. Could move all recipes to archive/ subfolder and only pull them out when we need a new build. Also could push packages to label and move to main once validated.
Other option: We could build packages offline.
DD – https://openforcefieldgroup.slack.com/archives/CFA4NL63E/p1593383590305000?thread_ts=1593029713.224000&cid=CFA4NL63E Is there a third strategy that is more short term? Add a job to .travis.yml that uses a Docker image with a more recent conda-build version. Add a file in each recipe that gives the conda-build version requirements e.g. conda-build==3.19.2 . Add a check that the conda-build version in use matches the criteria criteria given for the recipe; if yes, proceed; if not, don't build.
“““ DD – Do we care about recipes that are conda-build-3-incompatible? JRG – We could do one feedstock per project, so we don’t have to bring all the old projects along.
Just use omnia-dev and upload to main? Make conda-smithy feedstocks for each package
Long-term JW – Money approved to help get migration done. Just not sure how to approach topic. JRG – Could also try to make a conda-forge clone. But the real C-F could choose to block it at any time. JRG – Eastman would need to approve us doing blocklist. To him, conda-forge makes him do dangerous builds. SB – Could there be a blocklist “patch” on the C-F side? JRG – We could, but it would be in bad faith. SB – Could we make a carbon copy of the OpenMM system object? SB – We should have a deadline for OpenMM progress onto conda-forge
Further thoughts: SB – short-term, it’s not worth fixing omnia. If we can make GHAs that just make noarch packages, we’re good. DD – Can’t expect PE to change course on his preferred packaging approach. Do we need his agreement to distribute on C-F? SB – I think C-F requires developer agreement. MT – I don’t see anything in dev docs that require dev agreement, though they might choose to block us anyway.
JW – Need a short-term non-noarch solution for stuff like forcebalance, before we move it to C-F. SB – Building without dev permission would generate a lot of bad blood.
Decision JW will build noarch packages locally for evaluator and perses JW will build new FB locally if needed MT will work with LPW to move FB to C-F JRG will move forward with merging conda-recipes PR 1010, moving all existing packages to an archive/ subdirectory until we need to make a new build (this will prevent them from trying to rebuild ALL packages due to naming scheme change) JW will coordinate meeting between stakeholders to see what we can do to move OpenMM to C-F
|