Update using_as_module.md to document config parameter#2879
Conversation
📝 WalkthroughWalkthroughDocumentation updated to demonstrate a config-driven API using Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
Pre-merge checks✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
📚 Docs Preview: https://pr-2879.datamodel-code-generator.pages.dev |
CodSpeed Performance ReportMerging #2879 will not alter performanceComparing
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2879 +/- ##
=======================================
Coverage 99.38% 99.38%
=======================================
Files 91 91
Lines 15648 15648
Branches 1849 1849
=======================================
Hits 15552 15552
Misses 50 50
Partials 46 46
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Breaking Change AnalysisResult: No breaking changes detected Reasoning: This PR (#2879) is a documentation-only change that updates docs/using_as_module.md to document the new config parameter pattern introduced in previous PRs (#2874, #2877, #2878). The PR modifies only the documentation file with 62 insertions and 12 deletions, showing the new GenerateConfig and parser config class patterns. The documentation explicitly maintains backward-compatible keyword argument examples, confirming the old API still works. Since no source code was changed in this PR - only documentation was updated - there are no breaking changes to code generation output, templates, API/CLI, defaults, Python version support, or error handling. This analysis was performed by Claude Code Action |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
docs/using_as_module.md (1)
130-167: Ensure clarity on recommended vs. backward-compatible approaches.The section now shows two approaches: config-based (recommended) and keyword-arguments (backward compatible). Both subsections use the same code output, which may be confusing. Consider clarifying that both approaches produce identical results.
The output section at line 215-236 could benefit from a brief note indicating that both code examples above it produce the same result, reinforcing that this is an API compatibility choice, not a functional difference.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
docs/using_as_module.md
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: py312-pydantic1 on Ubuntu
- GitHub Check: 3.10 on Ubuntu
- GitHub Check: 3.11 on macOS
- GitHub Check: 3.13 on macOS
- GitHub Check: py312-isort5 on Ubuntu
- GitHub Check: py312-isort6 on Ubuntu
- GitHub Check: 3.13 on Ubuntu
- GitHub Check: 3.10 on Windows
- GitHub Check: 3.13 on Windows
- GitHub Check: 3.11 on Windows
- GitHub Check: 3.14 on Windows
- GitHub Check: 3.12 on Windows
- GitHub Check: Analyze (python)
- GitHub Check: benchmarks
🔇 Additional comments (3)
docs/using_as_module.md (3)
164-164: Both parser initialization patterns are correctly supported. TheJsonSchemaParserconstructor accepts theconfigparameter as documented at line 164, and also supports keyword-argument-based initialization (e.g.,data_model_type,data_model_root_type) as shown at line 191. The patterns are mutually exclusive by design—the baseParserclass validates that you cannot mix them simultaneously.
203-213: Parser config classes table is complete and accurate.The table at lines 207-211 correctly documents all available parsers and their corresponding config classes: JsonSchemaParser/JSONSchemaParserConfig, OpenAPIParser/OpenAPIParserConfig, and GraphQLParser/GraphQLParserConfig. No additional parsers exist in the codebase.
33-37: No issues found. All config instantiation patterns in the documentation match the actual class definitions. Parameter names and types are correct for all examples (lines 33-37, 53-55, 90-96, and 157-163).
|
|
||
| ```python | ||
| from datamodel_code_generator import InputFileType, generate, DataModelType | ||
| from datamodel_code_generator import InputFileType, generate, GenerateConfig, DataModelType |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if GenerateConfig is exported from the main module
echo "=== Checking GenerateConfig in datamodel_code_generator/__init__.py ==="
cat datamodel_code_generator/__init__.py | grep -n "GenerateConfig"
# Check for JSONSchemaParserConfig
echo ""
echo "=== Checking JSONSchemaParserConfig ==="
rg "class JSONSchemaParserConfig" --type python
# Check for GeneratedModules
echo ""
echo "=== Checking GeneratedModules ==="
rg "class GeneratedModules|GeneratedModules" --type python | head -20
# Check for get_data_model_types
echo ""
echo "=== Checking get_data_model_types ==="
rg "def get_data_model_types" --type python
# List what's actually exported from __init__.py
echo ""
echo "=== Checking __all__ in datamodel_code_generator/__init__.py ==="
grep "__all__" datamodel_code_generator/__init__.py -A 50Repository: koxudaxi/datamodel-code-generator
Length of output: 163
🏁 Script executed:
# Check key imports with specific line limits
echo "=== GenerateConfig in __init__.py ==="
rg "GenerateConfig" datamodel_code_generator/__init__.py --max-count=5
echo ""
echo "=== JSONSchemaParserConfig location ==="
rg "class JSONSchemaParserConfig" --type python --max-count=5
echo ""
echo "=== GeneratedModules location ==="
rg "class GeneratedModules" --type python --max-count=5
echo ""
echo "=== get_data_model_types location ==="
rg "def get_data_model_types" --type python --max-count=5
echo ""
echo "=== Checking __init__.py __all__ export list ==="
rg "^__all__" datamodel_code_generator/__init__.py -A 30 --max-count=1Repository: koxudaxi/datamodel-code-generator
Length of output: 543
🏁 Script executed:
# Find the datamodel_code_generator module
echo "=== Locating datamodel_code_generator module ==="
fd -t d "datamodel_code_generator" | head -5
# List top-level directory structure
echo ""
echo "=== Repository root structure ==="
ls -la | head -20
# Find __init__.py files
echo ""
echo "=== Finding __init__.py files ==="
fd "__init__\.py" | grep datamodel | head -10Repository: koxudaxi/datamodel-code-generator
Length of output: 1638
🏁 Script executed:
# Check main __init__.py for exports
echo "=== Checking src/datamodel_code_generator/__init__.py ==="
head -100 src/datamodel_code_generator/__init__.py | grep -E "GenerateConfig|GeneratedModules|__all__|import"
echo ""
echo "=== Searching for GenerateConfig definition ==="
rg "class GenerateConfig|^GenerateConfig" src/ --max-count=5
echo ""
echo "=== Searching for JSONSchemaParserConfig ==="
rg "class JSONSchemaParserConfig" src/ --max-count=5
echo ""
echo "=== Searching for GeneratedModules ==="
rg "class GeneratedModules" src/ --max-count=5
echo ""
echo "=== Searching for get_data_model_types ==="
rg "def get_data_model_types" src/ --max-count=5Repository: koxudaxi/datamodel-code-generator
Length of output: 1765
🏁 Script executed:
# Check __all__ in main __init__.py
echo "=== Checking __all__ in main __init__.py ==="
rg "^__all__" src/datamodel_code_generator/__init__.py -A 50
echo ""
echo "=== Checking if JSONSchemaParserConfig is in main __init__.py imports ==="
grep -n "JSONSchemaParserConfig" src/datamodel_code_generator/__init__.py
echo ""
echo "=== Check what the docs file actually imports on line 20 ==="
sed -n '15,25p' docs/using_as_module.md
echo ""
echo "=== Check imports on other lines mentioned (47, 74, 138) ==="
sed -n '42,52p' docs/using_as_module.md
echo "---"
sed -n '69,79p' docs/using_as_module.md
echo "---"
sed -n '133,143p' docs/using_as_module.mdRepository: koxudaxi/datamodel-code-generator
Length of output: 2697
🏁 Script executed:
# Check for DataModelType
echo "=== Searching for DataModelType ==="
rg "class DataModelType|DataModelType.*=" src/datamodel_code_generator/__init__.py | head -10
echo ""
echo "=== Check full imports in main __init__.py that aren't in __all__ ==="
rg "^from|^import" src/datamodel_code_generator/__init__.py | grep -E "GenerateConfig|DataModelType" | head -10
echo ""
echo "=== Check what DataModelType actually is ==="
rg "class DataModelType|DataModelType\s*=" src/ --max-count=10Repository: koxudaxi/datamodel-code-generator
Length of output: 883
🏁 Script executed:
# Get full imports section from main __init__.py
echo "=== Full import section of main __init__.py ==="
head -80 src/datamodel_code_generator/__init__.py | tail -40
echo ""
echo "=== Check if DataModelType is imported in main ==="
grep "DataModelType" src/datamodel_code_generator/__init__.py
echo ""
echo "=== Check full __all__ list to confirm ==="
grep -A 50 "^__all__" src/datamodel_code_generator/__init__.py | grep -E "DataModelType|GenerateConfig"Repository: koxudaxi/datamodel-code-generator
Length of output: 1775
🏁 Script executed:
# Check the enums import in main __init__.py more carefully
echo "=== Check enums imports in main __init__.py ==="
rg "from datamodel_code_generator.enums import" src/datamodel_code_generator/__init__.py -A 15
echo ""
echo "=== Verify GenerateConfig is ONLY in TYPE_CHECKING ==="
grep -n "GenerateConfig" src/datamodel_code_generator/__init__.py
echo ""
echo "=== Check if there's runtime import of GenerateConfig elsewhere ==="
head -150 src/datamodel_code_generator/__init__.py | grep -n "GenerateConfig"Repository: koxudaxi/datamodel-code-generator
Length of output: 183
🏁 Script executed:
# Simple check: Can these be imported at runtime?
echo "=== Check DataModelType in main __init__.py (first 100 lines) ==="
head -100 src/datamodel_code_generator/__init__.py | grep -n "DataModelType"
echo ""
echo "=== Count GenerateConfig occurrences and context ==="
grep -B2 -A2 "GenerateConfig" src/datamodel_code_generator/__init__.py | head -20
echo ""
echo "=== Check if DataModelType is in the enums import ==="
sed -n '1,50p' src/datamodel_code_generator/__init__.py | grep -A 20 "from datamodel_code_generator.enums"Repository: koxudaxi/datamodel-code-generator
Length of output: 183
🏁 Script executed:
# Read first part of __init__.py to find all imports
wc -l src/datamodel_code_generator/__init__.py
# Read lines 1-50 to see initial imports
echo "=== Lines 1-50 ==="
sed -n '1,50p' src/datamodel_code_generator/__init__.py
# Then check around the TYPE_CHECKING section
echo ""
echo "=== Search for TYPE_CHECKING section ==="
grep -n "TYPE_CHECKING" src/datamodel_code_generator/__init__.pyRepository: koxudaxi/datamodel-code-generator
Length of output: 183
🏁 Script executed:
python3 << 'EOF'
import sys
# Read the main __init__.py file
with open('src/datamodel_code_generator/__init__.py', 'r') as f:
lines = f.readlines()
# Find TYPE_CHECKING import block
print("=== Checking TYPE_CHECKING block for GenerateConfig ===")
in_type_checking = False
for i, line in enumerate(lines[:100], 1):
if 'TYPE_CHECKING' in line:
in_type_checking = True
print(f"Line {i}: {line.rstrip()}")
elif in_type_checking:
print(f"Line {i}: {line.rstrip()}")
if 'GenerateConfig' in line:
print(" ^^^ GenerateConfig found in TYPE_CHECKING block")
if line.strip() == '' or (line[0] not in ' \t' and 'import' not in line):
in_type_checking = False
# Check if DataModelType is imported outside TYPE_CHECKING
print("\n=== Checking for DataModelType in runtime imports ===")
for i, line in enumerate(lines[:100], 1):
if 'DataModelType' in line and 'TYPE_CHECKING' not in line:
print(f"Line {i}: {line.rstrip()}")
EOFRepository: koxudaxi/datamodel-code-generator
Length of output: 183
🏁 Script executed:
# Try very simple file size check first
stat src/datamodel_code_generator/__init__.py
# Then use cat with head
cat src/datamodel_code_generator/__init__.py | head -80Repository: koxudaxi/datamodel-code-generator
Length of output: 183
🌐 Web query:
datamodel-code-generator GenerateConfig public API export import
💡 Result:
I’m not sure what you mean by “GenerateConfig” in the context of datamodel-code-generator. Do you mean:
- the CLI/module generate function and its config/options (using datamodel_code_generator.generate or CLI flags), or
- a specific class named GenerateConfig in another library, or
- exporting/importing a saved configuration (e.g., pyproject.toml / CLI flags) for datamodel-code-generator?
Tell me which one and I’ll give exact import/export code or commands (and examples).
Fix import path for GenerateConfig in documentation examples (lines 20, 47, 74, 138).
GenerateConfig cannot be imported from the main datamodel_code_generator module at runtime—it is only available for type checking. Update all documentation examples to import from the config submodule:
from datamodel_code_generator.config import GenerateConfiginstead of:
from datamodel_code_generator import GenerateConfigThe imports for JSONSchemaParserConfig (from datamodel_code_generator.config) and get_data_model_types (from datamodel_code_generator.model) are correct. GeneratedModules is also correctly exported from the main module.
🤖 Prompt for AI Agents
In docs/using_as_module.md around line 20 (and also update lines 47, 74, 138),
the examples import GenerateConfig from the top-level package which only exposes
it for type checking; change those imports to import GenerateConfig from the
config submodule (i.e., use from datamodel_code_generator.config import
GenerateConfig) so the examples work at runtime—leave other imports
(JSONSchemaParserConfig, get_data_model_types, GeneratedModules) as they are.
|
🎉 Released in 0.51.0 This PR is now available in the latest release. See the release notes for details. |
1 participant
Summary by CodeRabbit
New Features
GenerateConfigandJSONSchemaParserConfigclasses for more flexible module-based code generation configuration.Documentation
✏️ Tip: You can customize this high-level summary in your review settings.