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

Discussion: SQLAlchemy2 compatibility issue #478

Closed
Sheila-nk opened this issue Feb 21, 2023 · 8 comments · Fixed by #488
Closed

Discussion: SQLAlchemy2 compatibility issue #478

Sheila-nk opened this issue Feb 21, 2023 · 8 comments · Fixed by #488

Comments

@Sheila-nk
Copy link
Contributor

JupyterHub backported the sqalchemy compatibility fix to JupyterHub>=3.0 but didn't restrict the sqlalchemy version to < 2.0 for JupyterHub<3.0. Tests on GitHub Actions are failing due to this. More info: jupyterhub/jupyterhub#4312

Solutions suggested by @GeorgianaElena include:

Additional input is welcome.

@consideRatio
Copy link
Member

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:

  • jupyterhub>=1.0.0 (current requirement)
  • jupyterhub>=2.3.1
  • jupyterhub>=3.5.1
  • jupyterhub>=4.0.0

I suggest we go for python>=3.8 and jupyterhub>=4.0.0 to minimize long term complexity of maintaing this repo, thinking that its not so important that users without modern python or jupyterhub also get a modern version of this spawner.

@consideRatio
Copy link
Member

@minrk @manics what do you think about dropping support for older jupyterhub versions and or python versions?

I think it would be good to drop support for python 3.7 and jupyterhub 1 to enable pytest-jupyterhub to work against this repo, which requires py38+ and jupyterhub 2+ at least.

@manics
Copy link
Member

manics commented May 31, 2023

I think it's fine, especially if previous releases of DockerSpawner continue to work with older versions of JupyterHub.

@consideRatio
Copy link
Member

consideRatio commented May 31, 2023

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?

@manics
Copy link
Member

manics commented May 31, 2023

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.

@minrk
Copy link
Member

minrk commented May 31, 2023

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.

@consideRatio
Copy link
Member

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!

@minrk
Copy link
Member

minrk commented May 31, 2023

No worries! Reasonable people can disagree on the trade-offs. Thanks for all your work updating everything recently!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants