Looks good to me - does the Python 3.6 failure on TravisCI look like a glitch?

@bebatut you can probably use the same thing in #887

Yes and no, I'm assuming this is because you get some old python version if you don't specify python 2 in the build matrix. The warnings are printed to stderr, and that makes the set metadata tool fail.

Looks good to me - does the Python 3.6 failure on TravisCI look like a glitch?

It is a consequence of pyca/cryptography#4261 , introduced in cryptography 2.3.0 . We use 2.3.1 since Galaxy release 18.09 . Ubuntu Trusty (used in Travis) still uses python 2.7.5, which causes the warning to be printed on stderr by cryptography, making some tool fail.

This is a Galaxy issue though, do we want to force deployers to upgrade their python version, or do we want to ignore stderr messages in the set_metadata tool ?

@mvdbeek Something like the following?

diff --git a/lib/galaxy/datatypes/set_metadata_tool.xml b/lib/galaxy/datatypes/set_metadata_tool.xml
index 69c84dd..3c52a72 100644
--- a/lib/galaxy/datatypes/set_metadata_tool.xml
+++ b/lib/galaxy/datatypes/set_metadata_tool.xml
@@ -4,7 +4,7 @@
         <requirement type="package" version="1.5">bcftools</requirement>
     </requirements>
     <action module="galaxy.tools.actions.metadata" class="SetMetadataToolAction"/>
-    <command>"\${GALAXY_PYTHON:-python}" "${set_metadata}" ${__SET_EXTERNAL_METADATA_COMMAND_LINE__}</command>
+    <command detect_errors="exit_code">"\${GALAXY_PYTHON:-python}" "${set_metadata}" ${__SET_EXTERNAL_METADATA_COMMAND_LINE__}</command>
     <configfiles>
         <configfile name="set_metadata">from galaxy_ext.metadata.set_metadata import set_metadata; set_metadata()</configfile>
     </configfiles>

Yes. But this will also bite deployers on all tools that require galaxy's virtualenv and that determine the state based on the presence of messages on stderr.

But this is a good change, I think, we should have this regardless.

I'm not much convinced it would fix anything though, since the set_metadata part of the galaxy_JOBID.sh job script would still print the message on the job stderr, causing the tool to fail.

Right, but it seems more appropriate to work with exit codes anyway. The right thing from the deployer side is certainly upgrading python, those warnings aren't there for no good reason.