Because we are a library and not an end application, we need to relax our dependencies, so that our users have the most leeway to choose the version of our sub-dependencies that they want (for example if they have hvac as a direct dependency or if another of their dependencies has hvac as a sub-dependency).
By leaving the upper constraint open (we just want hvac >= 0.10.6), users can keep the "old" version they already had, or use a newer version if they want/have to (because of a sub-dependency). If a later hvac version breaks pydantic-vault, user can always pin the sub-dependency version to something that works with all their dependencies...
This was initially implemented by @area42 in PR #18, I redid it on top of the new main branch because I changed all other dependency versions and there was too many conflicts ^^' Thank you for your contribution!
Because we are a library and not an end application, we need to relax our dependencies, so that our users have the most leeway to choose the version of our sub-dependencies that they want (for example if they have hvac as a direct dependency or if another of their dependencies has hvac as a sub-dependency). By leaving the upper constraint open (we just want hvac >= 0.10.6), users can keep the "old" version they already had, or use a newer version if they want/have to (because of a sub-dependency). If a later hvac version breaks pydantic-vault, user can always pin the sub-dependency version to something that works with all their dependencies...
This was initially implemented by @area42 in PR #18, I redid it on top of the new main branch because I changed all other dependency versions and there was too many conflicts ^^' Thank you for your contribution!
Supersedes: #18