[PATCH 3/5] dts: use Pydantic in the configuration

[Luca Vizzarro]

On 30/09/2024 18:56, Nicholas Pratte wrote:
>> +the YAML test run configuration file and validates it against the :class:`Configuration` Pydantic
>> +dataclass model. The Pydantic model is also available as
> 
> Out of curiosity, what is the reason for maintaining use of
> dataclasses here as opposed to creating BaseModel subclasses for the
> Pydantic library? I suppose both implementations would lead to the
> same result, but is it mostly for the sake of familiarity and
> consistency that we're still using dataclasses here?

The original idea was as you said, familiarity and consistency, but it 
actually brings extra headaches and it's unnecessary. I've used 
BaseModel for everything in the newer versions.

>>   @unique
>> -class TrafficGeneratorType(StrEnum):
>> +class TrafficGeneratorType(str, Enum):
>>       """The supported traffic generators."""
>>
>>       #:
>> -    SCAPY = auto()
>> +    SCAPY = "SCAPY"
> 
> Going off of Juraj's comments, would you be able to provide an deeper
> explanation as how this new parameterization of str and enum works
> with respect to the Pydantic field discriminators?

This is something I am not able to explain unfortunately. For some 
reason – I am not 100% sure how Pydantic works in this case – the 
original implementation was incompatible with the discriminator. 
Retaining the original setup made Pydantic use values of:

  "<TrafficGeneratorType.SCAPY: SCAPY>"

instead of plain "SCAPY", for some reason. So it's an incompatibility issue.