Open mattwthompson opened 3 years ago
As an example of implementations that attempt to solve these issues, the toolkit's feedstock has been split into separate recipes (ignoring OpenEye, since it it not distribute on conda-forge
and therefore cannot be part of the requirements):
openff-toolkit
: Covers enough dependencies to use most - but not all - of the API.openff-toolkit-base
: Installs the same as above, but without RDKit or AmberTools, therefore missing out on most of the important functionality in the API, i.e. Molecule.from_smiles
, Molecule.generate_conformers
, ForceField.create_openmm_system
, and many others. (OpenMM should eventually be stripped out in this package, but the toolkit currently has SimTK units too deeply interwoven to make this an optional dependency.)openff-toolkit-examples
(not merged yet): Covers enough to run all examples. (Unclear to me how well this matches up with the entirety of the API, but it should be pretty close).A benefit to doing this in packaging is that is directly specifies what users install based on which "kind" of the toolkit they want. The major downside, in my opinion, is that it only serves as implicit documentation, i.e. somebody not familiar enough with conda-forge
infrastructure would have a hard time figuring out of package X is required or optional.
OK, this is great. Are you asking for help identifying the core cases to be supported? I wonder if a poll of our team or something similar is an efficient way to get the feedback you need.
Copying what I wrote several months ago in Confluence (which largely still holds true):