tests: add bool tests

[euri10]

hi @DanCardin :)

I had a debug attribute that didnt change from the default when changing values in my .env file, I'm using a msgspec Struct, so I ended up writing a hopefully correct test for bool values only :)

My guess is that only pydantic has it "correct" because it handles type coercion oob, idk if it's feasible to have the same behaviour for others, if not a mention in the docs might be interesting, bool values in .env is a hard topic so......

[DanCardin]

perhaps you know msgpack better than me, i dont see way to perform runtime mapping logic on raw values besides post_init

I'm fairly certain I dont want to, by default, perform arbitrary opinionated mapping conversions on any type (including bool), that very much seems in the realm of Pydantic(validatator)/attrs(converter) or perhaps a property on dataclass

With that said, in the context of this lib i can see the usefulness for having something baked in for bools, so i could perhaps instead imagine:

class Foo(Struct):
    foo: Annoated[Bool, Env('FOO')]

where that's something like:

@dataclass
class Parser:
    """Sentinel class used to preform pre-mapping on raw values coming from the loader."""

@dataclass
class Bool(Parser):
    truthy_values: Sequence[str] | None = {"1", "true", "t", "yes", "y"}
    falsey_values: Sequence[str] | None = None

    def __call__(self, value: Any):
        if self.truth_values:
            if value in self.truthy_values:
                return True
            return bool(value)
        if falsey_values:
            if value in self.falsey_values:
                return False
           raise ValueError("Invalid value...")
        return False

so when you dont like my personal above decision to not include "on" in the set, you could type Bool = Annotated[bool, dataclass_settings.Bool({"1", "true", "t", "yes", "y", "on"}). but essential point being the library would be looking for such an annotation to perform pre-mapping on the value

[euri10]

i agree with you and would prefer not to have opiniated conversion, it's always less transparent to the user and imho an inferior dx, the fact it works with pydantic is just a reflexion of their design mixing validation and conversion I think.

I like the flexibility you propose, I was putting on because of the click link i put in the issue, but it's completely arbitrary and ofc if one has the power to change it, then it's the best of both worlds to me.