Arvados

22001-run-tests-py3 @ 4bdfa65dcf896b93a020a247c163167019ddca05 - developer-run-tests: #4348

The first part, dropping the :py3 suffix, was easy enough. Backwards compatibility required a little more argument mangling than I maybe would've liked but it's still straightforward.

The second part, dropping Python 2 support, is a little more complicated. There was no explicit support in the code. But there were a lot of remnants from that time: unused variables, virtualenv parameters, workarounds for distutils/easy_install issues, etc. I cleaned all that up as a matter of maintainability.

• All agreed upon points are implemented / addressed.
  • See above
• Anything not implemented (discovered or discussed during work) has a follow-up story.
  • N/A
• Code is tested and passing, both automated and manual, what manual testing was done is described
  • See above. Also teste manually running tests both with and without the :py3 prefix, both interactively and not.
• Documentation has been updated.
  • Updated the run-tests.sh usage message, which is the only place it appears in the code. Can update the wiki after the branch is merged.
• Behaves appropriately at the intended scale (describe intended scale).
  • No change in scale
• Considered backwards and forwards compatibility issues between client and server.
  • Yes, explicitly maintains backwards compatibility by dropping the :py3 suffix from user input.
• Follows our coding standards and GUI style guidelines.
  • N/A (no such guidelines for shell)

• It looks like there're some more cases where _version.py is expected, I'm seeing some "ModuleNotFoundError: No module named 'arvados._version'" at the above linked Jenkins job.
• Also, in the above link I can see that the sdk/python install phase runs twice, maybe we can shave a couple seconds there?

Other than that, LGTM

Lucas Di Pentima wrote in #note-3:

• It looks like there're some more cases where _version.py is expected, I'm seeing some "ModuleNotFoundError: No module named 'arvados._version'" at the above linked Jenkins job.

Thank you for catching that. It's more of a problem of not installing the Python SDK early enough. Fixed in e625e885445e91f1c50c4df8c2c9be6544509333 - see comments for discussion - developer-run-tests: #4349

• Also, in the above link I can see that the sdk/python install phase runs twice, maybe we can shave a couple seconds there?

This is basically necessary to accommodate interactive use of run-tests.sh, at least with the script's current structure. Imagine you're hacking on the Python SDK and running the tests in an interactive session. run-tests.sh needs to install the Python SDK at launch in order to run run_test_server.py. Then, every time you run test sdk/python, it needs to re-install the Python SDK in case you added any dependencies, etc. A non-interactive run goes through the same code paths, so that's why it ends up installing twice: once at launch, and once when it starts the tests.

For a non-interactive run we could skip multiple installs, but that requires coordination between the functions that's difficult to arrange in shell. At the very least, it's a big enough job that I think it's out of scope for this ticket. If you'd like to file this as a feature request, please do.

This LGTM, thanks!