Min RK

I think this issue is mostly resolved by the fact that jupyterhub 2.0 does not specify any CLI arguments, nor place any requirements on the CLI signature of the launch...

> Do we want KubeSpawner to override cmd? The default is less important to me; what's important to me is that the "use the image's command" case is clear and...

From a technical perspective, if we do support this feature, I think it should be through making `sudo` work in `post-build`, not adding a new file (as discussed in #192)....

> Could you weigh-in on that? Speed and size costs of using conda definitely vary a lot. Mamba has no effect on size, but does significantly improve dependency resolution time....

> separating all potentially image-breaking specifications Given how much we install in the user-space, I don't think that's true. It's really easy to create a broken image with postBuild already....

I still think that *if* this needs a new special repo2docker-only file, it's not a feature we should add. > is cleaner than enabling then disabling sudo I also think...

Are you still seeing the 'halting hub...' message, but the hub does not halt? That's how kubespawner is meant to recover from things like this (when in doubt: restart). So...

OK, if you're seeing the 'halting hub...' message, that means kubespawner has _recognized_ something's wrong, decided to do the right thing that will fix it (confirmed by the fact that...

One way to find out: ``` kubectl exec -it hub-... -- pip list ```

OK, then it's got every fix I'm aware of. Is it possible to capture more detailed logs from the hub? Maybe even with debug-logging on? The trick is likely that...