Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider relaxing the upper bounds on some requirements #2485

Closed
sscherfke opened this issue Jan 31, 2024 · 2 comments · Fixed by #2506
Closed

Consider relaxing the upper bounds on some requirements #2485

sscherfke opened this issue Jan 31, 2024 · 2 comments · Fixed by #2506
Labels
enhancement New feature or request
Milestone

Comments

@sscherfke
Copy link
Contributor

Description

Many requirements of nicegui have upper bounds. I understand the principal need for this, but upper bounds can make repackaging harder or using nicegui in larger environments tricky.

For example, setuptools is pinned to <50, but Nicegui works just fine with recent versions. Aiofiles is pinned to < 24.0.0 but this makes not sense with cal-ver, because the first release of this year is not necessarily more likely to introduce breaking changes than the last release of 23.*.

And, out of curiosity, why did you re-add aiohttp as requirement? It seems nowhere to be used. The links to the "dependabot issues" in the corresponding commit don't work.

@falkoschindler
Copy link
Contributor

Thanks a lot for these suggestions, @sscherfke! Let me share my thoughts:

  • We try to relax requirements where possible, but also had some bad experiences with loose upper bounds (looking at you, FastAPI). Nevertheless, it's good to re-evaluate the requirements regularly.
  • I'm not sure why we introduced setuptools<50 two years back. We can probably remove the upper bound.
  • Regarding aiofiles: I wasn't aware of cal-ver and that aiofiles is using it. It totally makes sense to remove the upper bound - at least if we don't restrict the minor version.
  • aiohttp is used by python-engineio and had a security issue in <3.9.2. The dependabot page is probably private, which is why you can't access it. Here is the corresponding CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-23829.

Would you like to create a pull request relaxing the mentioned (and maybe more) dependencies? 🙂

@sscherfke
Copy link
Contributor Author

Thanks for the quick reply :-)

I’ll open a PR in the next few days.

sscherfke added a commit to sscherfke/nicegui that referenced this issue Feb 3, 2024
- The "^" specifier is often too restrictive for 0.* versions so I would
  not recommend to use it in these cases:
  https://python-poetry.org/docs/dependency-specification/
- Markdown2: The issue from 2.4.11 was fixed in 2.4.12:
  - zauberzeug#2154
  - trentm/python-markdown2#546
  - https://github.com/trentm/python-markdown2/blob/master/CHANGES.md#python-markdown2-2412
- Watchfiles: Doesn't look like v1 will introduce breaking changes:
  samuelcolvin/watchfiles#186
- python-multipart: "^0.06" is "==0.0.6" which is too strict and
  at this stage, any release can potentially add breaking changes
- aiofiles: Uses CalVer and 24.0.0 is as likely to introduce breaking
  changes as 23.2.0.
- httpx: It does not look like 1.0.0 will introduce breaking changes
  (if you already fixed any deprecation warnings).  Testing against the
  1.0.0beata0 is advisable, though.
  encode/httpx#3069
- ifaddr: Development is rather slow, package looks quite stable.
  I don't think that a 0.3.0 will add breaking changes and a 1.0 is not
  in sight.
- pytest-asyncio: Restriction to >=0.19,<0.20 seems unwanted and updates
  are needed for recent pytest versions
- pytest: Has there been a reason to not support pytest7?  pytest8
  currently breaks some plugins, but this should be fixed soon.

Fixes: zauberzeug#2485
@falkoschindler falkoschindler added this to the 1.4.14 milestone Feb 3, 2024
@falkoschindler falkoschindler added the enhancement New feature or request label Feb 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants