Compute service local transformation registry

Compute Service Local Transformation Registry

Summary

Automatically discover, enumerate, and register all available chemical identifier conversion jobs across local compute and web service converters, then validate and serialize them into a unified Job manifest. This skill ensures that all source-to-target transformation routes (e.g., SMILES→InChI, name→CAS) are discoverable and callable at runtime.

When to use

Apply this skill when initializing a chemical metadata annotation pipeline and you need to: (1) establish which identifier conversions are available across your installed converter suite (CIR, CTS, PubChem, IDSM, BridgeDb, RDKit, custom); (2) validate that each conversion route can actually be invoked; (3) present users with a menu of supported transformations; or (4) route annotation requests to the correct converter and method.

When NOT to use

• When converters are already manually registered or hard-coded into the application — use registry discovery only when converters are plugin-based or directory-scanned.
• When you only need to perform a single, pre-known conversion route — job discovery overhead is unnecessary for one-off transformations.
• When converter availability changes frequently at runtime and you require real-time method introspection — this skill assumes stable, pre-launch discovery.

Inputs

• Converter class modules (web and compute) with init definitions of conversions list
• MSMetaEnhancer directory structure (MSMetaEnhancer/libs/converters/web/, compute/)
• Chemical identifier attribute names (e.g., 'name', 'inchi', 'smiles', 'cas_number')

Outputs

• Unified Job registry (in-memory data structure)
• Serialized Job manifest file (JSON/structured format listing all conversions)
• Validated converter instance pool with dynamically generated conversion methods

How to apply

Load the ConverterBuilder module and call its auto-discovery mechanism to introspect all converter classes in MSMetaEnhancer/libs/converters/web/ and MSMetaEnhancer/libs/converters/compute/ directories. For each discovered converter, extract its conversions list (defined in __init__) as tuples of (source_attribute, target_attribute, conversion_method_name). Invoke create_top_level_conversion_methods() on each converter to trigger dynamic method generation. Aggregate all tuples into a unified Job registry, where each Job is a (source_attr, target_attr, converter_name) triple. Validate that each Job's conversion method exists and is callable (async for WebConverters, sync for ComputeConverters). Finally, serialize the complete Job manifest to a structured file (JSON or similar) listing all available conversions for downstream annotation workflows.

Related tools

• ConverterBuilder (Auto-discovers, instantiates, and aggregates all converter classes and their conversion methods into a unified Job registry) — https://github.com/RECETOX/MSMetaEnhancer
• CIR (Web service converter providing chemical structure identifier conversions (e.g., InChI↔SMILES)) — https://cactus.nci.nih.gov/chemical/structure_documentation
• CTS (Web service converter for chemical identifier transformations) — https://cts.fiehnlab.ucdavis.edu/
• PubChem (Web service converter fetching chemical metadata including SMILES, InChI, and CAS number) — https://pubchem.ncbi.nlm.nih.gov/
• IDSM (Web service converter for chemical structure queries and identifier lookups) — https://idsm.elixir-czech.cz/
• BridgeDb (Web service converter for identifier mapping and cross-referencing) — https://bridgedb.github.io/
• RDKit (Compute converter for local chemical descriptor and structure transformation (no external API calls)) — https://github.com/RECETOX/MSMetaEnhancer

Examples

from MSMetaEnhancer.libs.utils.ConverterBuilder import ConverterBuilder
from MSMetaEnhancer.libs.converters.web import CTS, CIR, IDSM, PubChem, BridgeDb
from MSMetaEnhancer.libs.converters.compute import RDKit

ConverterBuilder.register([CTS, CIR, IDSM, PubChem, BridgeDb, RDKit])
job_registry = ConverterBuilder.build_job_registry()

Evaluation signals

• All converter classes from web/ and compute/ directories are discovered and instantiated without import errors.
• Each discovered converter's conversions list is non-empty and contains valid (source_attr, target_attr, method_name) tuples.
• Every Job in the registry has a corresponding callable method on its converter instance (verify method exists via hasattr and inspect.iscoroutinefunction for async/sync mismatch).
• The serialized Job manifest is valid JSON/structured format, contains ≥6 distinct converters (CIR, CTS, IDSM, PubChem, BridgeDb, RDKit), and includes at least one job per converter.
• Validation logic detects and reports broken jobs (missing methods, mismatched async/sync signatures) without crashing the registry build.

Limitations

• If converters are installed as optional dependencies (e.g., RDKit via conda), missing packages will silently skip those converters unless explicitly declared as required.
• API rate limits on web service converters (CIR, CTS, PubChem, IDSM, BridgeDb) are not captured in the Job registry itself; rate limiting is enforced at call time, not discovery time.
• The registry reflects the converters' hardcoded conversions lists at initialization; new conversion routes added to a converter after Application startup will not appear in the registry without re-initialization.
• Cross-converter dependency chains (e.g., 'name→inchi via IDSM, then inchi→formula via RDKit') are not automatically discovered; only direct single-converter routes are enumerated.

Evidence

• [other] 1. Load the ConverterBuilder module which automatically discovers and instantiates all available converters from MSMetaEnhancer/libs/converters/web/ and MSMetaEnhancer/libs/converters/compute/ directories.: "Load the ConverterBuilder module which automatically discovers and instantiates all available converters from MSMetaEnhancer/libs/converters/web/ and MSMetaEnhancer/libs/converters/compute/"
• [other] 2. For each discovered converter (CIR, CTS, IDSM, PubChem, BridgeDb, RDKit, and any custom converters), extract the conversions list defined in its init method as tuples of (source_attribute, target_attribute, conversion_method_name).: "For each discovered converter (CIR, CTS, IDSM, PubChem, BridgeDb, RDKit, and any custom converters), extract the conversions list defined in its init method as tuples"
• [other] 3. Invoke the create_top_level_conversion_methods() call on each converter to trigger dynamic method generation based on the conversions list.: "Invoke the create_top_level_conversion_methods() call on each converter to trigger dynamic method generation based on the conversions list."
• [other] 4. Aggregate all discovered Job tuples across web and compute converters into a unified Job registry, where each Job represents one (source_attr, target_attr, converter_name) triple.: "Aggregate all discovered Job tuples across web and compute converters into a unified Job registry, where each Job represents one (source_attr, target_attr, converter_name) triple."
• [other] 5. Validate that each Job's conversion_method exists as an async method (for WebConverters) or sync method (for ComputeConverters) on the corresponding converter instance.: "Validate that each Job's conversion_method exists as an async method (for WebConverters) or sync method (for ComputeConverters) on the corresponding converter instance."
• [other] MSMetaEnhancer fetches chemical metadata including SMILES, InChI, and CAS number from five external services: CIR, CTS, PubChem, IDSM, and BridgeDb: "MSMetaEnhancer fetches chemical metadata including SMILES, InChI, and CAS number from five external services: CIR, CTS, PubChem, IDSM, and BridgeDb"
• [readme] ConverterBuilder.register([CTS, CIR, IDSM, PubChem, BridgeDb, RDKit]): "ConverterBuilder.register([CTS, CIR, IDSM, PubChem, BridgeDb, RDKit])"
• [readme] specify requested jobs = [('name', 'inchi', 'IDSM'), ('inchi', 'formula', 'IDSM'), ...]: "jobs = [('name', 'inchi', 'IDSM'), ('inchi', 'formula', 'IDSM'), ('inchi', 'inchikey', 'IDSM')"