Open lewisacidic opened 8 years ago
To be a lot more concrete, the plugin/extension architecture I see as allowing third party packages to register Featurizer
s, Standardizer
s, GeometryOptimizer
s etc. that can then be imported as part of the library if they are installed.
We spin out the ChemAxon wrappers into skchem_chemaxon
, which are untestable in CI and provide a hard to satisfy dependency.
The directory structure might be
skchem_chemaxon
├── README.md
├── setup.py
└── skchem_chemaxon
├── features
│ ├── atom.py
│ ├── fingerprint.py
│ └── mol.py
└── standardizers
└── standardizer.py
As an example, we could find any top level packages matching skchem_*
and import the relevant packages/modules, allowing the project structure to be extended by third parties without having to get things from different top level packages.
>>> mf = skchem.features.MorganFeaturizer()
>>> type(mf)
skchem.features.fingerprints.MorganFeaturizer
>>> cxf = skchem.features.ChemAxonFeaturizer()
>>> type(cxf)
skchem_chemaxon.features.mol.ChemAxonFeaturizer
>>> skchem.standardizers.get('cx_feat')
And probably more things.
This might be a bit unnecessary on reflection, as it isn't that hard to just import from the correct module, just saw this was what they do with flask
extensions.
We could have a plugin infrastructure, for each of the external tools, and for example the interact module.