Feat: also support `mise` in addition to `tox`

[mattcristal]

Mise can be used for the same goals as tox.

This is the case because tox is just being used as a matrix for tasks runner. mise can achieve the same.

I would like mise to also be allowed, or even recommended as a default over tox.

[mattcristal]

cc @b-per

[b-per]

Hi! We don't really use mise in any OSS work today so I am not sure we want to start using it just for this package

[mattcristal]

Hi! We don't really use mise in any OSS work today so I am not sure we want to start using it just for this package

I see, but it is something that would you be also open to "support"?

For example see: godatadriven/dbt-date#68

As developers and contributors to a dbt package, we would still like to be 'compliant' with the official way of developing dbt packages yet being able to implement, in this case, mise.

[b-per]

Opened a draft PR exploring this alongside the uv migration from #22: #31

Same caveat as over there — this is not a commitment to merge as-is, it's meant to gather feedback and check whether it represents what you had in mind for mise support. The approach: tox stays the default (so existing consumers are unaffected), and a new test_runner: "mise" input lets a package opt in to running mise run test:<adapter> against its own mise.toml instead. The task-naming convention (test:<adapter> / test:fusion-<adapter>) is modeled on what's already in the dbt-date mise PR (godatadriven/dbt-date#68).

Curious whether this "tox by default, mise opt-in per package" shape addresses the concern here, short of dbt Labs adopting mise more broadly.

cc @mattcristal @boxysean @pgoslatara