2020-05-11 Namespace hacking

Date

May 11, 2020

Participants

• @Matt Thompson

• @David Dotson

• @Simon Boothroyd

Objectives

1. Hack together a minimal “metapackage” to see if there are immediate significant roadblocks

What we did

1. Installed cookiecutter

2. Made an “openff” metapackage to host stubs

3. Removed COC, `data/`, `openff.py`, travis.yml

4. First up is moving openff-evaluator into metapackage

5. Copied distributed.py from Dask, updated error message and import to import evaluator

6. Did from openff import evaluator to check that error message is triggered (it was!)

7. Remove devtools/, copy evaluator/devtools/, and update some files inside

8. conda install openff-evaluator -c conda-forge -c omnia -c omnia/labels/beta

9. Modified GHA script from evaluator’s, mostly by removing things and changing names

10. import openff works!

11. from openff import evaluator works! and evaluator.<tabcomplete> shows the stuff you’d expect

12. Copied README badges over

13. Commit changes, create repo on GitHub

14. Matt tested the repo out of the box and the two above imports worked

15. Run linters (isort, black, flake8) locally

16. Configure flake8

Discussion topics that came up

• How should the metapackaged be versioned? Should it be versioned?

  • Probably yes, should be versioned

  • But updates should mostly be bugfix type of changes

    • Mostly just if a new package is added to this collection

• Dask’s very simple try: from distributed import * ; except ImportError seems to work well

• the toolkit’s bare high-level init causes problems for imports, since there are no module-level imports

  • import openforcefield; dir(openforcefield) has nothing in it

  • this “dask-like” approach requires that everything in a module be available at the first import

• Pure namespace approach seems …. not easy?

  • Pretty much non-existent in the community

Action items

Discrete discussion points for later (assign as action items at a later meeting, maybe tomorrow)

Decisions