[Issue]: Dependency version specifications are too loose

[bitnom]

trafficstars

The current loose version specifications are a problem. I'm about to file a related bug report where the openai version is the likely culprit, and resolving that specific issue will not prevent similar problems being ever-present.

Relevant to #1155

[davorrunje]

For frameworks, dependency versions should be as loose as possible to make them applicable to a wide range of applications. On the contrary, dependency versions for applications should be tight to make deployments more stable and robust.

[bitnom]

For frameworks, dependency versions should be as loose as possible to make them applicable to a wide range of applications. On the contrary, dependency versions for applications should be tight to make deployments more stable and robust.

I agree. However, the dependency versions should not be non-existent:

dependencies = [
    "diskcache",
    "flaml",
    "openai>=1.3",
    "python-dotenv",
    "termcolor",
    "tiktoken",
    "pydantic>=1.10,<3"
]

In other words, the absence of a version range shouldn't be included in "Possible." It's impossible since we don't know what breaking changes might be introduced in a dependency tomorrow. A new dependency version should at least be proven to pass our tests before the repo is allowed (And all its users forced) to bump to it.

I would start by using <=<current_version> for all dependencies. Then, set out to determine the lower-bounds of what's possible, and specify them as well. Once we have that, we don't even need to deal with bumping minor versions ourselves. The trendy thing these days is to use dependabot to auto-bump to any minor version which passes our tests, though that's perhaps best left to a separate issue, and must be enabled in the repo settings.

[davorrunje]

I agree, at least minimum versions should be specified. Preferably, maximum versions as well because at least a major version upgrade will break something. I added the pydantic dependency above myself using that principle. Supporting both 1.10.x and 2.x versions is a major headache, but must be done because there are too many environments using an older version.

[davorrunje]

I would start by using <=<current_version> for all dependencies. Then, set out to determine the lower-bounds of what's possible, and specify them as well. Once we have that, we don't even need to deal with bumping minor versions ourselves. The trendy thing these days is to use dependabot to auto-bump to any minor version which passes our tests, though that's perhaps best left to a separate issue, and must be enabled in the repo settings.

The minimum version should be the minimum for which the framework works, not the latest one. If we fix the latest version, that will create deps conflicts for many applications.

[ekzhu]

@bitnom how's your experience with dependabot? Does it automatically run all workflows I have with each newer version of dependency?

[davorrunje]

@bitnom how's your experience with dependabot? Does it automatically run all workflows I have with each newer version of dependency?

It bumps a version if it is fixed one and creates a pull request. That PR will trigger whatever workflow is defined for new PR. Here is one example of how it looks in practice:

https://github.com/airtai/faststream/pull/1120

For no-fixed version it doesn't do anything so it is limited to dev deps in frameworks which are typically the only fixed ones.