Openff-toolkit: Migrate openforcefield to openff.toolkit

[SimonBoothroyd]

Description

This issues tracks the progress of migrating the openforcefield package to the new openff-toolkit and the openforcefields package to the new openff-forcefields. The will involve

• renaming the openforcefield repository to openff-toolkit and the openforcefields repository to openff-forcefields.
• making a new release of the conda-packages as openff-toolkit and openff-forcefields.
• migrating the openforcefield package to a namespace package with imports changing from import openforcefield to import openff.toolkit.

The rationale for this change is to improve clarity of where this package fits into the overall OpenFF ecosystem, and to make it consistent with the other core OpenFF packages (openff-evaluator, openff-recharge, openff-system, openff-benchmark...)

Notes

• The version of the openforcefields package is intrinsically tied to the version of the latest force field that it contains (e.g. openforcefields=1.3.0 contains the openff-1.3.0.offxml force field and its predecessors). This currently prevents the openforcefields package from being migrated to a full name space package as it would require a new release of the package without a new force field being released.

  The current consensus is to go ahead with the renaming of the openforcefields repository, and to release a new conda package under the name of openff-forcefields=1.3.0. It will install into a directory called openforcefields, and will still be importable by openforcefields but will show up in conda list / be conda installable as openff-forcefields.
  On the next FF release we will simultaneously perform the namespace migration and FF release.

  While not ideal, there isn't really a better alternative without resorting to hacky alternatives (patching the install in conda, creating a tag which doesn't properly follow semver... etc...) or by breaking the parity between the package version and the force field version.

Migration Plan

The migration should proceed as follows:

1) ~add depreciation warnings to the repository stating that after 0.8.3 the package will need to be imported as openff.toolkit, rather than openforcefield (#805).~

2) ~cut a new release of the package as 0.8.3 and release on omnia only. After this release no new features should be merged into master until the 0.9.0 release has been made.~

3) ~rename the openforcefield repository to openff-toolkit and the openforcefields repository to openff-forcefields.~

4) ~release the smirnoff99frosst and openff-forcefields packages on conda-forge only. (tag https://github.com/conda-forge/staged-recipes/pull/13657)~

1) ~do a cursory scan of http://openforcefield.org/ to check for any unexpected broken links~

5) ~perform the namespace migration and remove the deprecation warning created by 1). (#803)~

6) ~cut a new "release" (tag) of the package as 0.9.0rc1~ and release on conda-forge only. (tag https://github.com/conda-forge/staged-recipes/pull/13689)

1) run tests against 0.9.0rc1 in downstream packages to check for regressions or any unforseen bugs

1) cut a new release of the package as 0.9.0 and release on conda-forge only.

1) after a feedstock exists, point a specific README link to it (see https://github.com/openforcefield/openff-toolkit/pull/813/files#r557512274)

7) Begin the migration of the other OpenFF core packages to use the new openff-toolkit import, cut releases for each, and migrate each on conda-forge.

[mattwthompson]

Might it be worth stipulating a feature freeze while this happens? So, any new features (even PRs that are ready to go) in the toolkit that are not strictly necessary for this migration should be targeted for for 0.9.1. This would avoid having more moving parts than necessary while all these changes take place.

[SimonBoothroyd]

That's the intention and what we agreed upon. I've updated the checklist to state that explicitly.

[j-wags]

Perfect. This looks good to me.

[mattwthompson]

Just poked through some (but not all) links on the website and everything seems to be redirecting as expected

[mattwthompson]

Should there by anything in the docs/README along the lines of "this project used to be called openforcefield ... " so that people don't think this is a new project?

[SimonBoothroyd]

I think that's a good call - feel free to push something to the migration branch!

[mattwthompson]

Another detail (that doesn't need to be addressed in the scope of this migration) is whether or not we want to update the RTD URL at some point

[mattwthompson]

I've slightly updated the list above to reflect our decision to start with a release candidate of 0.9.0 before the proper release/pre-release