Importing everything in utils module

[ijpulidos]

Description

Importing all members of the utils.py submodule.

In previous changes we created a openmm.utils package/module with a utils.pysub module for the sake of organizing and modularizing many of the utility functions we have in openmmtools. By doing so I mistakenly only imported some of the members of the modules instead of importing all of them.

Todos

• Implement feature / fix bug
• Add tests
• Update documentation as needed
• Update changelog to summarize changes in behavior, enhancements, and bugfixes implemented in this PR

Status

• Ready to go

Changelog message

We are now importing all the members of the new `utils.py` submodule by default. Recovers previous behavior of importing utils with `from openmm.utils import ...`, avoiding API breaking changes.

[ijpulidos]

This should fix the problems importing the openmmtools utils in downstream packages, such as in choderalab/yank#1286 and choderalab/yank#1299

[mikemhenry]

Do we really want to import everything into the namespace?

[mikemhenry]

I haven't skimmed through to make sure that we don't have collisions, if this is exactly how it was working, then that is fine.

[ijpulidos]

Good question, there's no easy way to know what packages downstream are using, my first attempt was trying NOT to import everything, and only the things that openmmtools itself was needing, but it's hard to tell what other packages are using from utils.py so the easiest way is to import everything. I think in the future we probably want to remove the utils.py file and just have submodules that make more sense (such as what we did with the gentle equilibration utility function)

[ijpulidos]

I haven't skimmed through to make sure that we don't have collisions, if this is exactly how it was working, then that is fine.

Yeah, it should be analogous to what was happening before the changes, such that users can still do import openmmtools.utils (or similar)

[mikemhenry]

Okay then I think it is okay! If we ever do a big breaking change, we can cleanup the API but for now lets make downstream life easy

[mikemhenry]

@ijpulidos looks like the tests need fixing (or change the import to be backwards compatible)

[ijpulidos]

@ijpulidos looks like the tests need fixing (or change the import to be backwards compatible)

I think you were right on doubting using the * from the start :). I think we just need to be explicit on the imports. I don't know about the details, but apparently private attributes/variables/members (those that start with an underscore for example) are not imported when we do from module import * .

[codecov]

Codecov Report

Merging #698 (b328194) into main (c491c3d) will not change coverage.
The diff coverage is n/a.

[mikemhenry]

Can you run a sort on these? Or can I?

[mikemhenry]

LGTM, I ran a sort on the imports