This PR addresses persistent UserWarnings related to field names in Pydantic models that were previously thought to conflict with protected namespaces within Pydantic's internal mechanics. Despite attempts to rename fields to avoid these conflicts, warnings continued to be raised, suggesting fields like model_identifier and model_storagepath conflicted with a protected namespace "model".
Issue Description:
Warnings were encountered as follows:
UserWarning: Field "model_identifier" has conflict with protected namespace "model_".
UserWarning: Field "model_storage_path" has conflict with protected namespace "model_".
These warnings suggested a conflict with Pydantic's internal namespace, misleadingly pointing towards the resolution to set model_config['protected_namespaces'] = (), which is not supported by Pydantic's public API or documentation.
Resolution:
Upon further investigation and discussion, I was determined that the direct advice provided by the warnings was not applicable, as Pydantic does not officially support a model_config['protected_namespaces'] configuration. Therefore, the approach to resolve these warnings involved:
Field Renaming: Fields initially named model_name and model_path were renamed to model_identifier and model_storage_path to attempt to avoid the namespace conflict. Given the continued warnings, further renaming was considered to completely avoid prefixes that might be causing issues, though specific renames are subject to project context and were not implemented in this PR.
Suppressing Warnings: While not a resolution to the root cause, warnings specific to these fields were suppressed to avoid cluttering the application logs. This approach was taken as a temporary measure while seeking further clarification or updates from Pydantic's documentation or community support channels.
Community Engagement: Recommended reaching out to the Pydantic community for insights or potential undocumented features related to namespace management that could explain the warnings and suggest a proper resolution.
Testing:
After the changes in the Model and the train code I run the test in the lab running:
Summary:
This PR addresses persistent UserWarnings related to field names in Pydantic models that were previously thought to conflict with protected namespaces within Pydantic's internal mechanics. Despite attempts to rename fields to avoid these conflicts, warnings continued to be raised, suggesting fields like model_identifier and model_storagepath conflicted with a protected namespace "model".
Issue Description:
Warnings were encountered as follows:
These warnings suggested a conflict with Pydantic's internal namespace, misleadingly pointing towards the resolution to set model_config['protected_namespaces'] = (), which is not supported by Pydantic's public API or documentation.
Resolution: Upon further investigation and discussion, I was determined that the direct advice provided by the warnings was not applicable, as Pydantic does not officially support a model_config['protected_namespaces'] configuration. Therefore, the approach to resolve these warnings involved:
Field Renaming: Fields initially named model_name and model_path were renamed to model_identifier and model_storage_path to attempt to avoid the namespace conflict. Given the continued warnings, further renaming was considered to completely avoid prefixes that might be causing issues, though specific renames are subject to project context and were not implemented in this PR.
Suppressing Warnings: While not a resolution to the root cause, warnings specific to these fields were suppressed to avoid cluttering the application logs. This approach was taken as a temporary measure while seeking further clarification or updates from Pydantic's documentation or community support channels.
Community Engagement: Recommended reaching out to the Pydantic community for insights or potential undocumented features related to namespace management that could explain the warnings and suggest a proper resolution.
Testing:
After the changes in the Model and the train code I run the test in the lab running:
curl -i POST http://localhost:5000/train -H "Content-Type: application/json" -d '{"file":"sensor_data.pkl", "identifier":"model", "storage_path":"./", "test_size":25, "ncpu":4, "mlflow_tracking_uri":"./mlruns", "mlflow_experiment":"apples01"}'having success results :
and verifying in the MLFlow UI:
For the lab4 after the changes:
For the lab7 after the changes: