[REF-2127] Loosen requirements

[picklelo]

Discussed in https://github.com/orgs/reflex-dev/discussions/2770

^{Originally posted by mahrz24 March 4, 2024}
I really like the looks of reflex dev so far and would like to use it at my company for internal dev tooling to replace streamlit as it would serve the purpose much better.

However, this is currently made impossible by the quite strict down pinning of a lot of dependencies. As we develop the tools in a larger repository I end up in a lot of conflicts. But even with a standalone tool our security policies frequently require me to update to the latest versions of packages that fix some CVEs or other security issues.

While I can see the case for semantic versioning and down pinning to the major version. In reality this only works in a library if you frequently evaluate if there are newer compatible version and are very quick to lift upper bounds. Sadly with reflex this isn't the case. Maybe a better approach would be to open up most upper boundaries and rely on CI pipelines to ensure compatibility with latest version of libraries.

_REF-2127

[mahrz24]

As mentioned in the discussion, I tested it with mostly relaxed dependencies and locally it looked good. If you want I can try to prepare a PR.

One problem though is, that the reflex-hosting-cli package also down pins httpx (among others, but this is the one which caused the problems on my side). If I am not mistaken that package is not on github (at least not publicly), so here I am not sure how to solve this as a contribution.

Otherwise it seems that down pinning mainly stems from platform incompatibilities (I saw a PR with an issue of httpx 0.26 on windows) which could made platform dependent.

Another larger chunk is pydantic, which can be solved by having conditional imports to the .v1 module, which means being compatible with v1 and v2 but still using v1 API.

To be alerted early on breaking dependencies I would add either one dimension or one branch to the test matrix and test once with the poetry.lock file as is and once with a lock file generated at test time. If only the latter fails it's a good hint to which upper boundary needs to be added or how a compatibility with old and new version can be reached. Another solution and probably saving a bit on CI execution time would be to have a job that performs locking in regular intervals and only opens a PR if all tests passed successfully.

[martinxu9]

@mahrz24 I can match the requirements between the reflex-hosting-cli and reflex. For the most part, have been trying to do that. If you have any recommendations for the CLI package and don't mind sharing your findings, I'd happy to merge them in. As far as I remember, there's only a couple of dependencies on the CLI package that are not part of the core reflex