You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Following up on #408 and #409 that solves it, we can encounter problems when versions of dependencies change.
One thing is that without upper bounds on most of the packages, when the API changes, some functions that FawltyDeps use may not work the same way. Even more fragile situation is with importlib_metadata, where we use internal functions which have no guarantees of staying unchanged with a new release.
Another thing that may happen is a drift of dependencies bounds. Lower bounds of FawltyDeps dependencies may be too low. Given that we develop the code in the environment with newer dependencies, we may unknowingly use some feature only available in a later version without update of the lower bound for dependency version.
Describe the solution you'd like
For the first problem, we may use depednabot, which can manage version updates. It uses a yaml file, where the updates frequency, how to group updates and other settings may be declared. It supports poetry package ecosystem.
For the second problem, and the similar considerations, a nox action that creates a separate test environment, where it pins versions of the dependencies would be a good solution. It is beyond what poetry can offer, and we should consider scripting this process ourselves.
Describe alternatives you've considered
The problem with version bounds is common to many packages. It is worth searching for an existing opensource solution to test different configurations of dependencies versions.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Following up on #408 and #409 that solves it, we can encounter problems when versions of dependencies change.
One thing is that without upper bounds on most of the packages, when the API changes, some functions that FawltyDeps use may not work the same way. Even more fragile situation is with
importlib_metadata
, where we use internal functions which have no guarantees of staying unchanged with a new release.Another thing that may happen is a drift of dependencies bounds. Lower bounds of FawltyDeps dependencies may be too low. Given that we develop the code in the environment with newer dependencies, we may unknowingly use some feature only available in a later version without update of the lower bound for dependency version.
Describe the solution you'd like
For the first problem, we may use depednabot, which can manage version updates. It uses a yaml file, where the updates frequency, how to group updates and other settings may be declared. It supports poetry package ecosystem.
For the second problem, and the similar considerations, a nox action that creates a separate test environment, where it pins versions of the dependencies would be a good solution. It is beyond what poetry can offer, and we should consider scripting this process ourselves.
Describe alternatives you've considered
The problem with version bounds is common to many packages. It is worth searching for an existing opensource solution to test different configurations of dependencies versions.
The text was updated successfully, but these errors were encountered: