-
Notifications
You must be signed in to change notification settings - Fork 308
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
Discussion: SQLAlchemy2 compatibility issue #478
Comments
In #485 I made us install sqlalchemy specifically when testing with jupyterhub 1 and 2, but I think we should drop support for older jupyterhub versions as well to help us maintain things a bit easier long term. I suggest dropping support for jupyterhub 1 at least, and preferably also more, to protect us from handling issues in due time. Here are some options:
I suggest we go for |
I think it's fine, especially if previous releases of DockerSpawner continue to work with older versions of JupyterHub. |
Thank you @manics for chiming in! Did you mean you think its fine to drop support for py37 and jupyterhub 1, or also to drop support for jupyterhub 2-3? |
Everything 😄 . Development is slow/stable enough that it should be fine to keep using an old version of DockerSpawner if you need an unsupported version of JupyterHub or Python. If this repo was getting lots of bug fixes then the case for supporting older versions would be stronger. Edit: In the unlikely event there's a secvuln we could consider backporting it to the previous major release of Dockerspawner. To make this easier I think dropping Python <=3.7 and JupyterHub<=4 should be a major release. |
I very strongly disagree with dropping support for super recent versions, especially of hard-to-upgrade packages like JupyterHub, as I think it puts the convenience of maintainers too far above users. I think this is a temptation we should work very hard against. For example, we are still currently recommending that users install JupyterHub 1.5, via the-littlest-jupyterhub, as we haven't yet made a release with the 4.0 bump. Upgrading JupyterHub is a big deal, and forcing users to upgrade JupyterHub should be considered a big cost we are passing on to users. While there are some issues with the test suite with older versions of JupyterHub that aren't getting updates (mainly pinning sqlalchemy, are there any other issues?), none of them actually present compatibility issues with this package that I'm aware of. I'd support bumping to 3.8 and 2.3.1, but I don't thing we should drop 3.5.1 unless supporting 3.5.1 is causing a significant problem today. In general, I do not believe it is appropriate to drop support before a problem is identified. The more out-of-date a release is, the lower the bar for dropping support vs fixing whatever problem it is, but I think proactively dropping support is a pattern to avoid. |
Thank you @minrk and I'm sorry for having you advocate this in a few repos! Let's go with python>=3.8 and jupyterhub>=2.3.1! |
No worries! Reasonable people can disagree on the trade-offs. Thanks for all your work updating everything recently! |
JupyterHub
backported thesqalchemy
compatibility fix to JupyterHub>=3.0 but didn't restrict thesqlalchemy
version to < 2.0 for JupyterHub<3.0. Tests on GitHub Actions are failing due to this. More info: jupyterhub/jupyterhub#4312Solutions suggested by @GeorgianaElena include:
Additional input is welcome.
The text was updated successfully, but these errors were encountered: