Fix Publishing Workfiles

[BigRoy]

Is there an existing issue for this?

• I have searched the existing issues and added correct labels.

Description

Current Behavior

Currently publishing of workfiles fails to integrate due to the workfiles being folders instead of individual files.

Expected Behavior

Publishing should work as intended, even though it is a folder. That folder should just be tracked as the resource to handle.

An alternative could be to match ayon-harmony integration and instead of dealing with workfiles being folders we .zip them up on workfile save/load and/or publish. However, this has the downside that we're deviating slightly from default Silhouette workflow which just happens to be using folders instead. If we were to use .zip this would also mean that any deadline rendering with "published workfile" would internally require some logic to deal with a .zip file instead of a Silhouette project folder - which could mean additional logic inside the Deadline Silhouette plug-in.

Preferably needing to .zip the content can be avoided.

Steps To Reproduce:

1. Publish workfile.

Additional context:

Version

Version of the server, ayon-core and the addon that's affected

What platform were you running when you found the bug?

Windows
Linux - Rocky9
Linux - Ubuntu
MacOS

You can also provide any additional information relevant to the issue.

Relevant log output:

[BigRoy]

Asked around to hear whether there's any way to have Silhouette handle projects as "files" instead of "folders" here: https://forum.borisfx.com/t/silhouette-saved-projects-are-folders-or-are-they/19594

[BigRoy]

Thanks @philippe-ynput @antirotor for the comments on the PR: ynput/ayon-core#1113.

As I understand now, we will not integrate the project files as folders, but will instead be working with .zip.

This introduces however quite some complications:

• I need to add .zip to the supported file extensions of the host integration so that one, in workfiles tool can "Copy & Open" the published workfiles (otherwise they won't be listed.)
• This then means the artists can also save .zip in the workfiles area via the workfiles tool (it's an option to save as .zip)
• However, Silhouette requires the project to be unzipped to open. So then I unzip that folder on open, but now I have a 'workfile' that is .zip and .sfx (the unzipped one) living next to each other in work area, both being listed in the workfiles tool.
• The alternative to that is to delete the .zip on open. However, if someone then uses Browse... to open a zipped file then suddenly we're deleting a users .zip on their machines in random places?

Opening a workfile then becomes:

        # Support .zip (zipped project workfiles)
        zipped_filepath = None
        if filepath.endswith(".zip"):
            # Unzip the file
            zipped_filepath = filepath
            unzipped_filepath = lib.unzip(filepath)
            filepath = unzipped_filepath

        result = fx.loadProject(filepath)

        # If we opened a .zip and the project loaded succesfully, then remove
        # the zip IF the .zip is in AYON_WORKDIR (because those .zip should
        # only live there temporarily on "Copy & Open" from published workfiles
        # in the workfiles tool)
        if result and zipped_filepath and issubdir(zipped_filepath, 
                                                   AYON_WORKDIR):
            os.remove(zipped_filepath)

And saving becomes:

        project = _get_project()
        if not project:
            return

        use_zip = filepath and filepath.endswith(".zip")
        zipped_filepath = None
        if use_zip:
            zipped_filepath = filepath
            filepath = filepath[:-4]  # Remove .zip extension
            filepath += ".sfx"        # Add .sfx extension

        # Consider `None` value to be saving into current project path
        args = (filepath,) if filepath else ()
        project.save(*args)

        if use_zip:
            # zip the saved project folder
            lib.zip_and_move(filepath, zipped_filepath)
            os.remove(filepath)  # Remove the temporarily saved folder

Seems rather overkill?