Module Map & Exports
Relevant source files
The following files were used as context for generating this wiki page:
The flext-target-ldif project is structured as a Singer Target designed to output LDAP Data Interchange Format (LDIF) files. It utilizes a modular architecture where core logic is separated into models, writers, and utilities, all coordinated through a main target class. The project follows the FLEXT ecosystem patterns, emphasizing strict typing, lazy loading, and standardized integration points with Singer and Meltano.
Sources: README.md:1-15, src/flext_target_ldif/target.py:1-15
Export Architecture & Lazy Loading
The project employs a lazy-loading mechanism to optimize performance and manage the public API surface. Exports are defined in specialized mapping files and registered during package initialization. This ensures that heavy dependencies or submodules are only loaded when explicitly accessed.
Lazy Import Mapping
The core of the export system resides in _exports_lazy_part_01.py, which utilizes build_lazy_import_map to link internal submodules to their public-facing class names and shorthand aliases.
The diagram shows how the package root delegates attribute access to internal modules via a lazy map.
Sources: src/flext_target_ldif/init.py:53-95, src/flext_target_ldif/_exports_lazy_part_01.py:8-45
Public API Surface
The following aliases and classes are exposed as the primary interface for the module:
| Alias | Target Class/Module | Description |
|---|---|---|
m | FlextTargetLdifModels | Unified access to LDIF entities and sink models. |
u | FlextTargetLdifUtilities | Data processing and transformation helpers. |
t | FlextTargetLdifTypes | Type hints and Pydantic validation schemas. |
c | FlextTargetLdifConstants | Shared constants and configuration defaults. |
p | FlextTargetLdifProtocols | Abstract interfaces and return types. |
Sources: src/flext_target_ldif/init.py:44-80, src/flext_target_ldif/_exports_lazy_part_01.py:12-40
Internal Module Map
Core Target Implementation
The FlextTargetLdif class in target.py serves as the entry point for the Singer Target. It manages configuration validation and orchestrates the creation of stream-specific sinks.
- Target Initialization: Merges default settings (like
file_naming_pattern) with user-provided JSON mappings. - Sink Management: Dynamically instantiates
m.TargetLdif.Sinkfor each incoming Singer stream. - Validation: Uses
FlextTargetLdifSettings(derived from Pydantic) to enforce domain rules on the configuration.
Sources: src/flext_target_ldif/target.py:20-80
Data Models and Sinks
The models.py file contains the FlextTargetLdifModels class, which aggregates all LDIF-specific data structures. It includes nested classes for formatting options, entry representations, and the Singer Sink implementation.
This diagram illustrates the hierarchical relationship between domain models and the operational Sink.
Sources: src/flext_target_ldif/models.py:32-70, src/flext_target_ldif/models.py:170-220
Writer and Transformation Logic
The FlextTargetLdifWriter is responsible for the physical serialization of records into RFC-compliant LDIF strings. It handles line wrapping (default 78 characters), Base64 encoding for sensitive or non-ASCII characters, and Distinguished Name (DN) generation via templates.
write_record: Buffers and prepares individual Singer records._generate_dn: Applies thedn_templateto record values._write_attribute: Logic for determining if an attribute value requires::(Base64) or:(Standard) notation.
Sources: src/flext_target_ldif/writer.py:30-150, src/flext_target_ldif/utilities.py:90-120
Utilities Module
FlextTargetLdifUtilities provides helper methods for string manipulation and LDAP-specific data formatting. It includes a RecordTransformer for normalizing data types (e.g., converting booleans to "TRUE"/"FALSE").
Sources: src/flext_target_ldif/utilities.py:20-250
Conclusion
The Module Map & Exports system in flext-target-ldif provides a robust, lazy-loaded interface that separates Singer protocol management from LDIF-specific serialization logic. By leveraging the FLEXT core lazy-loading patterns, the project maintains a clean public API while ensuring that complex models and writers are initialized only when a data stream is processed.