Fix version sorting when comparing str and int with python 3

[dsagilles]

When configuring multiple app versions in settings/tk-multi-launchapp.yml or within shotgrid, there is a call to _sort_versions() which relies on distutils.version.LooseVersion.

In python-2, the call _sort_versions(["prod", "1.2.3"]) would return ["prod", "1.2.3"] (as expected), however, in python-3, the call fails entirely with an error like TypeError: '<' not supported between instances of 'str' and 'int'. This causes the associated app to silently disappear from the launcher.

This PR propose an alternate sorting method which guarantees no comparison between int and str can occur.

[julien-lang]

When configuring multiple app versions in settings/tk-multi-launchapp.yml

Thanks for your contribution @dsagilles. Could you provide more information about this part, please? A detailed use case would be useful and/or a config that creates this issue.

Thanks.

[carlos-villavicencio-adsk]

Is prod a version that can happen? It should not as it doesn't comply with PEP 440.

I think the recommended way is to move from LooseVersion to packaging.version, see: pypa/distutils#22 (comment)

Let me know your thoughts.

[dsagilles]

@julien-lang :
Here is an example of one of our typical "nuke" launcher setup section in config/env/includes/settings/tk-multi-launchapp.yml:

# nuke
settings.tk-multi-launchapp.nuke:
  engine: tk-nuke
  icon: "{target_engine}/icon_256.png"
  linux_path: "@path.linux.nuke"
  mac_path: "@path.mac.nuke"
  windows_path: "@path.windows.nuke"
  menu_name: Launch Nuke {version}
  versions: ['prod', '14.0v5']
  hook_before_app_launch: "@common.hooks.tk-multi-launchapp.before_app_launch"
  location: "@apps.tk-multi-launchapp.location"

And our nuke path setting is:

path.linux.nuke: xterm -T pp-launch-nuke-benuts -e "export PP_OVERRIDE_NUKE_VERSION={version} && pp-launch-nuke-benuts || { echo '===== Command failed with status $? =====' ; cat ; }"

The "prod" version gets expanded by our pp-launch-nuke-benuts to the latest prod-safe version number.
This config was working in python-2 but not anymore in python-3 as the token str(prod) and int(14) cannot be compared.
I suspect other studios may be using versions as "tags" as well and will have issues transitioning their launcher from python-2 to python-3

@carlos-villavicencio-adsk :
While prod is indeed not PEP-440-compilant, there is no mention of such restriction in the versions setting description at info.yml. It simply mentions A list of strings.
Moreover, if I'm not mistaken, the public nuke versioning scheme (ex: 14.0v5), which is mentioned as an example in the description, is not PEP-440 compliant either.

I think a more relaxed sorting method should be preferred over packaging.version as apps version numbers (like nuke) may not comply. Something similar to the way the Rez packaging system does it would be ideal : Rez Version Wiki , as I suspect many studios using it will want their Shotgrid launcher versions to match their Rez packages.

Finally, if you do think packaging.version is more adequate, I believe it should be made clear in the setting description that versions must be PEP-440 compliant and not random strings in order to work.

Thanks you both for your support, have a good day !

[carlos-villavicencio-adsk]

I totally agree with you that this should allow a flexible naming. The current documentation was made back in the Python 2 days when we didn't face this issue before.

It's a finding you're sharing with us, we appreciate it.

It is inevitable we should update things now. We're going to analyze which is the best option (can be your proposal, using packaging.version, update docs, etc.). We'll let you know in this 🧵 .