Open mbruhns opened 1 year ago
One idea would be to specify versions with >=
, build the package with Github actions triggered by commits (by new versions of external packages would be nicer but it's not immediately clear to me how to do that) and then make the version requirements more restrictive once something fails. Would require us to have 100% test coverage, at least on a very rudimentary level (every line of code should be at least somehow executed), such that we really see those failures.
Yehaa, tests! I hoped there would be a different solution 😅
Should be pretty simple integration tests: run the pipeline with the cross product of all possible method
configurations. Do we have a place where all possible options for the configuration is tracked?
True, but I was hoping for a tool that does this version matching for us automatically.
Since we're fairly restrictive regarding the compatible Python version (>=3.10), the required package versions should be as lenient as possible. This is especially important since users should be able to use this tool and pipe the output directly into another tool that is not considered in our pipeline.
Do you know of any best practices on how to relax the requirements while enabling stable builds?