Kian-Tat Lim / Tim Jenness Due to DM-9351, what I would like to is remove the ability to select the py version completely and hardwire it to run py2/3 and completely split sims off to a separate build, is that acceptable?

Running both py2 and py3 for all builds is fine by me.

My only concern is ci_hsc which still doesn't run under python 3. Aside from that one package I personally don't care if you remove the python control or default it to running both versions of python.

I think the origin of the the py3 break down is from a PR in September of 2016 which added the python job param with a default of 'py2' to the various EUPS products jobs that trigger stack-os-matrix builds: https://github.com/lsst-sqre/jenkins-dm-jobs/pull/10/files

Do to some shenanigans with jenkins plugin(s) used to implement the multi-select python build axis, there are some "quirks" with triggering a build from [another] build that happen when a build is manually launched from the UI.

1. The default value for the multi-select parameter is lost – meaning the calling build must specify the python parameter or a null value gets stringified as "null" and gums things up.
2. The parameter format is different than the defined default value. The default value must use comma delimiters while the calling build must use space delimiters.

I've fixed the default python axis to be py2 & py3. Hopefully, sufficiently pedantic warning comments have also been added to the code. ci_hsc has been restricted to be py2 only.

Changes have been merged to "production". I'm assigning the issue to myself to do a manual inspection that things are working correctly in that env.

No issues have been observed in production.