Loosen dependencies for more flexible installation

[athewsey]

As discussed here on StackOverflow:

1. Applications should generally lock dependencies to exact versions, for reliable deployment
2. Libraries should generally support broad dependency version ranges where practical, to accommodate installing them on a range of environments and using them in a range of downstream applications

I suggest that poetry.lock accomplishes (1) for users wishing to download fmbench from source, but users installing fmbench from PyPI fall in the camp of (2), and would like fmbench to play nicely with whatever other dependencies might be in their environment.

For stable libraries that follow semver, it seems like we should be able to trust caret requirements? For e.g. specifically I would think something like the below (which I haven't fully tested):

• ipywidgets 8.1.1 -> ^8.0.0 (unless we care about specific bug fixes they released?)
• transformers 4.36.2 -> ^4.36.2 (Idk which potentially new models you're consuming that might prevent downgrade)
• pandas 2.1.4 -> ^2.0.0(even this is only like a year old?)
• datasets 2.16.1 -> ^2.14.0 (2.14.0 has an important caching change)
• sagemaker 2.220.0 -> ^2.119.0 (Current SMStudio / SageMaker Distribution v1.8 version)
• litellm 1.35.8 -> ^1.35.8 (idk how far back we could push this?)
• plotly 5.22.0 -> ^5.15.0 (before which there were compatibility issues with Pandas 2.0)

For unstable libraries (seaborn, tomark, kaleido), maybe we could at least use tilde requirements to allow patch versions?

[aarora79]

Thanks for the detailed work on this. I do think that the developer workflow should create a new conda env with Python 3.11 and then build the fmbench package using poetry. I realize that it would be nice to not have to do that and just install it an existing python venv but am not sure if that would lead us down a rabbit hole of dependency version mismatch. I can try it and see if it works with the versions you have provided and see how far we get.