I have been trying to work with jupyterhub/jupyterhub-deploy-docker and I notice that there is little activity on the repo in the last few years. There are several open PRs with no responses from maintainers, and open issues also seem to go unresponded to. There are two notable forks which are more up-to-date; one from HighPerLab and the other from LCAS.
Is this repo no longer maintained? Should I be using the littlest jupyterHub server instead?
Unfortunately that repo is a bit lacking in maintenance as you’ve noticed. If TLJH fits your needs then use that, but there’s no reason not to use one of the other Docker deployments if you’ve checked it’s suitable. A lot of valuable JupyterHub contributions come from the wider Jupyter community, and if one of those other projects work please share your experiences here, it’ll help others!
I was drawn to jupyterhub-deploy-docker because it uses
docker-compose. Kubernetes is a tech I have yet to dive into and running on bare metal w/ systemd isn’t ideal.
There are several updated forks and I am sure I am not the only one willing to help maintain. The repo is nested under the jupyterhub organization and this level of neglect looks bad. The repo should point to one of the maintained forks and mark itself unmaintained in the README if nobody is going to care for it. I wasted time getting started with it before realizing the state of neglect.
Hi! Can you share a link to the repos you recommend?
There isn’t one that jumps out at me yet. I have started a list in this google spreadsheet. It seems like a lot of splintered implementations with no docs updates. I am on the fence about picking through all this or just abandoning it for another approach. The docs and system design on this repo just made more sense to me than the TLJH.
What is the suggested resolution here?
- leave the unmaintained project there and continute to confuse people
- add active maintainer(s)
- rm repo
- add deprecation (or unmaintained) note to README
I don’t mind helping maintain, but I don’t want to add another solo-maintainer repo under one of my gh organizations. I at minimum need someone who is willing to click “merge” on PRs to the
Thanks for volunteering! I’ll happily review and merge PRs updating versions if you tag me (
@minrk). Without maintainers, we should archive the repo. It’s the capacity to answer support questions across too many repos that I think we lack the most.
I think there’s a lack of clarity on the scope of the repo. It was never meant to be more than an example people could look to as reference. Definitely not a supported distribution which should get feature requests like nbgrader, new authenticators, etc. I think those are all out of scope.
If we keep the scope tight:
- simple docker-compose
- default docker-stacks image
Then the only real maintenance it should need are image updates, and the occasional adjustment due to changing best practices (e.g. roles replacing admin users in 2.0).