| package org.broadleafoverrides.config; | |
| import com.broadleafcommerce.solr.autoconfigure.SolrProperties; | |
| import com.broadleafcommerce.solr.autoconfigure.SolrServer; | |
| import org.apache.commons.exec.CommandLine; | |
| import org.apache.commons.exec.DefaultExecutor; | |
| import org.apache.commons.exec.Executor; | |
| import org.apache.commons.exec.PumpStreamHandler; | |
| import org.apache.commons.logging.Log; | |
| import org.apache.commons.logging.LogFactory; |
| /basedir/documents/ @myorg/squad1 | |
| /basedir/documents/otherplace @myorg/squad1 | |
| /basedir/ui/ @myorg/squad3 | |
| /basedir/preferences/ @myorg/squad2 |
Supporting code for some exploration on DataDog/dd-trace-py#3819.
Attempted in the context of a Django app. The settings.py file corresponds to the main Django settings.py, but code should be able to be extracted out to other library entrypoints.
An incomplete attempt at trying to allow pydantic.v1 models in FastAPI. My overall conclusion is this is probably a waste of time and too risky, likely adds more risk and takes more time than modifying all models to work with Pydantic v2. There are too many edge cases with FastAPI usage of the global fastapi._compat.PYDANTIC_V2 variable which gets resolved at import time.
FastAPI 0.115.5 and Pydantic 2.10.2
Invoke patch_v2_compat() before you do anything with the FastAPI application (like adding routes):
| """ | |
| The below tests the Pydantic 'extra' behavior between v1 and v2 | |
| We can see that 'extra' does indeed behave the same between v1 and v2 | |
| """ | |
| import pydantic as pydantic_v2 | |
| import pydantic.v1 | |
| from pydantic import ConfigDict |