Max version for dependencies restricts freedom for consuming projects

[m3brown]

Is your feature request related to a problem? Please describe.

Recently httpx had a security vulnerability posted that required an update to httpx==0.23.0.

openapi-python-client does not have a lot of dependencies, but httpx was one of them, and httpx was pinned to <0.23.0

The solution at the time was to bump the limit to 0.24.0

Some concerns with the 0.24.0 approach:

1. That only kicks the problem down the road. What if 0.23.0 also has a security vulnerability?
2. Projects were unable to update for ~10 days after the vulnerabilities were reported

I believe a better solution is to remove the max version for all dependencies. This allows clients the freedom to utilize the latest version, and puts less stress on the maintainers of this project to quickly respond to urgent PRs. The concern about untested versions is valid, but a test matrix can help with that.

While not a perfectly relevant example, the recommendation in the python.org documentation reflects my sentiment, notably the gaining the benefit of dependency upgrades part:

It is not considered best practice to use install_requires to pin dependencies to specific versions, or to specify sub-dependencies (i.e. dependencies of your dependencies). This is overly-restrictive, and prevents the user from gaining the benefit of dependency upgrades.

Describe the solution you'd like

1. Remove the max version for dependencies in setup.py and pyproject.toml jinja files
2. Consider: Updating the test pipelines to test known good versions, and the latest version (to ensure a dependabot PR for a new version fails if it has regressions)
3. Consider: Adding verbiage to the readme / license specifying known good versions

Describe alternatives you've considered

1. Make the max version a full major version bump ahead. For example, with httpx: <1.0.0

   • This has the same problem as the proposed solution:
     • Future versions (e.g. 0.25.0) are permitted but are "untested" for compatibility
   • It also has the same problem as the current solution:
     • A future update is blocked by the library (e.g. 1.0.0)

2. Rely on consuming projects to fork the setup.py/pyproject.toml templates (using --custom-template-path) to remove the max version restriction.

   • This is what my project did.
   • I strongly prefer to NOT fork templates from openapi-python-client unless I have to. Forking puts the onus on my project team to analyze and merge any upstream changes to those templates in the future, just because I needed to change one line.

Additional context Add any other context or screenshots about the feature request here.

[m3brown]

Related to #629

[dbanty]

I'm more concerned with the day-to-day usability of this project (not getting random errors at runtime from incompatible dependencies) than a small delay in updates while a Renovate PR comes in.

Ideally, security vulnerabilities are fixed in the current semver-compatible version so that there is no delay in upgrading. Hopefully, httpx will be stable (1.x) soon, so there will be less churn.