Change Details

Our bastions are still on stretch which use Python 3.5, but most people are trying to launch Python 3.7 webservices on k8s. When creating the venv, you have to do it in a k8s interactive pod (see https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Python#Creating_a_virtual_environment). If you do it on the bastion, you'll end up with confusing "ModuleNotFound" style errors. We should be able to automatically detect these mismatches in `webservice` when you try to launch a new webservice. Since the bastion is 3.5 and the venv should be 3.7, we could try to invoke `~/www/python/venv/bin/pip`, which, if correctly created, should fail due to the missing module error. I think it would be more reliable to simply check that `~/www/python/venv/bin/pip3.X` exists for whatever 3.X version you're trying to launch a webservice in. This seems more future proof.

Our bastions are still on stretch which use Python 3.5, but most people are trying to launch Python 3.7 webservices on k8s. When creating the venv, you have to do it in a k8s interactive pod (see https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Python#Creating_a_virtual_environment). If you do it on the bastion, you'll end up with confusing "ModuleNotFound" style errors. @bd808 suggested that we should be able to automatically detect these mismatches in `webservice` when you try to launch a new webservice. Since the bastion is 3.5 and the venv should be 3.7, we could try to invoke `~/www/python/venv/bin/pip`, which, if correctly created, should fail due to the missing module error. I think it would be more reliable to simply check that `~/www/python/venv/bin/pip3.X` exists for whatever 3.X version you're trying to launch a webservice in. This seems more future proof.

Our bastions are still on stretch which use Python 3.5, but most people are trying to launch Python 3.7 webservices on k8s. When creating the venv, you have to do it in a k8s interactive pod (see https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web/Python#Creating_a_virtual_environment). If you do it on the bastion, you'll end up with confusing "ModuleNotFound" style errors. We@bd808 suggested that we should be able to automatically detect these mismatches in `webservice` when you try to launch a new webservice. Since the bastion is 3.5 and the venv should be 3.7, we could try to invoke `~/www/python/venv/bin/pip`, which, if correctly created, should fail due to the missing module error. I think it would be more reliable to simply check that `~/www/python/venv/bin/pip3.X` exists for whatever 3.X version you're trying to launch a webservice in. This seems more future proof.