Best Practices Workshop Discussion

Date

Apr 22, 2020

Participants

  • @Jeffrey Wagner

  •  

Discussion topics

Item

Notes

Item

Notes

 

Unit handling

  • JW – Use pint?

  • MT – Would we have to make a converter between Pint and simtk units

  • JW – Yet, this is unavoidable

  • SB – One possible issue with pint is that the “all units, all the time”, the individual classes will have their own unit registries. There’s no easy way to convert between different unit registries. This would make units passed between classes/registries difficult

  • DD – Would we want to make an openff-units module? Would this be feasible?

  • SB – Yes, this could be a single place where we implement the pint-->simtk conversion, and use it throughout ecosystem

  • JW – Seems like we could choose to make a completely new context/registry, or use Evaluator’s or QCElemental’s

  • (General) – We want to use an existing one.

  • DS –

    >>> pc = qcel.PhysicalConstantsContext("CODATA2018") >>> type(pc.ureg) <class 'pint.registry.UnitRegistry'>

     

  • DS – Could fork QCElemental into MMOSS – Call it “Elemental”, and use it for model definitions

  • SB – Pint docs recommend creating a unit registry in top-level init, whereas example above builds a discrete context/unitregistry that must be called.

  • DS – The above implementation requires everything to keep the same implementation. The alternative is to use top-level ureg.

  • SB – If you explicitly define the physical constant context at the top, and then specify CODATA2018 , then it should be transferrable?

  • DS – If you call qcel.constants.ureg without specifying CODATA2018, then it could pull down different constants at different times

  • MT what are downside of doing it explicitly?

  • (General) – If we standardize on CD2018, and then some day we decide to switch to CD2020, this change might be rolled out unevenly, if different packages update at different times.

  • SB – If they all import units from the same place, then they should all change simultaneously.

  • DS – With implicit, everything will at least be internally consistent

  • SB – With explicit, there is more scope for things to fall out of sync - i.e. what if evaluator, toolkit and forcebalance hardcode different CODATA version strings?

  • DC – AMBER used a system of inertia, where they stuck to an initial set of values. Jason Swails tried to change, but was overruled. Changes at this point are so small as to be inconsequential.

When to refactor code/schedule major changes?

 

Release scheduling?

JW – Releases take me 2-3 days, but with more SS manpower, we can afford to do it more frequently

MT – Once we’re on conda-forge, we should save time on Omnia builds. Could make release notes require 2 approvals.

JW – We focus on pretty extensive release notes to help with migration, though could have less pontificating

MT – QCF and vanderbilt had pretty sparse release notes

 

Commit practices – Acronyms, gitmoji, message lengths

 

PR etiquette/Squash merging?

 

Branching and bugfixes on master vs. release tags

  • DD – We’re still a relatively small team, so we don’t want to pick a high-overhead model. A model where we separately maintain a bugfix-only branch, and a API-breaking branch, we will be overwhelmed.

  • MT – Agree that a two-branch solution will be a major pain. Parking API-breaking PRs will also hurt. What if we say “every month, we’ll release whatever is there, whether it’s a Y change or a Z change”

  • MT – Proposal:

    • After 0.7.0…

      • We do monthly Z releases

      • quarterly Ys

      • And allow for more frequent “bugfix” Zs

    • It is agreed

  • DD – This has the advnatage of knowing when Y’s will happen

  • (General) – This means that we park breaking PRs until a scheduled Y release

 

 

Action items

Decisions