May 2020 Developers Week Notes

Virtual devs week organization

• 15 minute break each hour

• End early if possible

Day 1:

• Round table updates

• Namespace reorgaization

• Create subgroup for QC dataset organizatiom

• (maybe) Slack channel discussion

Day 2:

Namespace reorganization

• Building support for something like from openff import toolkit, evaluator, ...)-- At least covering how we want the final namespaces/imports to look, and maybe getting into implementation of the changeover

• Full proposal: Infrastructure Architecture

  • Before I finalize everything with releasing the re-branded OpenFF Evaluator framework and commit to the new API naming conventions, I wanted to suggest we should invest some time to cleanup the software stack offered by OpenFF.While everything exists under the same GitHub org, there is almost no consistency between our packages. This will only get worse over time, and equally, will only get much harder to reverse as the user-base expands.i.e currently we have

    from evaluator import ...
    from openforcefield import ...
    from cmiles import ...
    ...

    while it would be much more cohesive to have an overall architecture similar to

    from openff.evaluator import ...
    from openff.toolkit import ...
    from openff.fractal import ...
    ...

    In practice this seems obtainable through an implicit namespace file structure like https://packaging.python.org/guides/packaging-namespace-packages/#native-namespace-packages while still maintaining individual repositories. This style of architecture / design would seem to lend itself to creating smaller, more focused repo's / packages (similar to more of a set of software 'microservices').I understand this would initially cause a large amount of disruption and possible confusion among users, but the end result would be a cohesive, elegant stack, with all the software we build being connected and identifiable under the same umbrella. Moreover, I believe it would push us to build software which more rigidly follows a single responsibility pattern, rather than monolithic packages which 'do everything' which the toolkit seems to be heading towards (especially if it simply just absorbs things like fragmenter and the QC submission frameworks).

    It would be fantastic to start moving away from a style similar to a zip file of disconnected tools, and to start planning longer term about how we want our software to look and be interacted with.

• Which packages should be under OFF namespace?

• What should namespace be called?

• When should the migration happen?

Determining best practices for QC dataset naming and organization

Migrating packages over to GitHub Actions and unifying under one OE license

Reorganizing/defining/consolidating the many development-related slack channels

Deciding upon a consistent approach and theme for each repos docs