Collect shot data for external artist

[mkolar]

We need a way of zipping up all relevant data for an artist (we'll start with compositing only) that can be triggered with a script from ftrack or nuke scene.

After internal discussion the plan is as follows.

• Create API function for converting relative to absolute paths and back (Anatomy environment replacement pype-setup#82)
• Create ftrack action that finds the latest workfile | convert paths to relative | parses is for any inputs and zips them all together (for now it will be implemented as custom avalon event server script to pype-config)
• Add script to Nuke to decode Environment Variables in paths

Ftrack Action

• find the latest workfile
• find all read nodes and make a list of inputs
• ensure they are all relative, and convert them if they are not
• send the workfiles and all the inputs to a zip file.
• save zip to deliverable folder

[cuID:PYPE-1138]

[mkolar]

Packaging script should be pype.api function probably so we can call it from hosts or externally (ftrack for example)

pype.api.pack_workfiles(asset, task, extension, version(optional) )

We certainly need at minimum:

• asset
• tasks
• extension (it is possible to have multiple workfiles type in the same task, so we need to filter the results to a particular type)

[iLLiCiTiT]

We certainly need at minimum:

And project_name.

[jakubjezek001]

At the moment I have done regex search for path in ASCI of "*.nk" file. Which is host related function and want work in any other host as those could be binary or has different syntax for file string tagging. My question is how will we differentiate in this global pype function for those different attributes?

Should't we add this specific functions for workfile collections into /pype/hosts/nuke/actions.py:workfile_packing and this global function will be looking for available function with workfile_packing namespace in host's action.py? Or better we could make it available as part of pype/hosts/nuke/workio.py.

[jrsndl]

Clients often require delivering Nuke "open project" when we get approval, so having package script as an Action sounds awesome!

Few scripts for Nuke are available on nukepedia.com. Possibly the best starting point is called WrapItUp. It takes care of many less obvious caveats, like duplicates, even collects Gizmos and Fonts. Also has a CLI.

What is IMHO missing is an easy way to add a folder for assets that are shared across more than one Shot, with ability to skip copy and relink to those instead. Wrapitup also doesn't collect custom OCIO config files.

Also adding an option to use server copy or linking would be great.

[jrsndl]

About use relative paths for all loaders and exports

Would you please consider making the read and write nodes relative to shot, not a Nuke Script?

Nuke project directory is forced one every Nuke load now (avalon/nuke/workio.py). Often not what is desirable.

Published Nuke scripts with paths relative to Nuke Script would need to have a mechanism to switch paths to absolute, and back to relative in published location.

On a side note, if you would decide to use nuke.scriptOpen instead of nuke.scriptReadFile, standard nuke autosave mechanism would work for scripts opened in Pype (tested in production).

nuke.scriptClear() nuke.Root().setModified(False) nuke.scriptOpen(filepath) # for autosave nuke.Root()["name"].setValue(filepath) nuke.zoomToFitSelected() # show all nodes, top left corner looks like empty script to artist nuke.Root().setModified(False)

[jakubjezek001]

What is IMHO missing is an easy way to add a folder for assets that are shared across more than one Shot, with ability to skip copy and relink to those instead. Wrapitup also doesn't collect custom OCIO config files.

@jrsndl very good point, we were not considering this at this point of project, but will add it to the project's todo.

Published Nuke scripts with paths relative to Nuke Script would need to have a mechanism to switch paths to absolute, and back to relative in published location.

What we had decided was to use the environment variable for whole project root and pack all resources the same way as they are in studio, so the outsourced work can come only as nk script and will work on client's pipeline without any remapping's.
Here is what we are going to implement for the Nuke Environment variables in paths.. http://timlehr.com/nuke-environment-variables-in-read-write/

[jrsndl]

What we had decided was to use the environment variable for whole project root and pack all resources the same way as they are in studio, so the outsourced work can come only as nk script and will work on client's pipeline without any remapping's.

So you plan to basically put what is in anatomy {root}/{project[name]} to the Nuke nuke.Root()["project_directory"] ?

I see an advantage in using nuke project_directory instead of [getenv X] in every file knob. When someone (for example client) tries to open the Nuke script outside pipeline, simply setting the root folder once in the script relinks everything.

[jakubjezek001]

What we had decided was to use the environment variable for whole project root and pack all resources the same way as they are in studio, so the outsourced work can come only as nk script and will work on client's pipeline without any remapping's.

So you plan to basically put what is in anatomy {root}/{project[name]} to the Nuke nuke.Root()["project_directory"] ?

I see an advantage in using nuke project_directory instead of [getenv X] in every file knob. When someone (for example client) tries to open the Nuke script outside pipeline, simply setting the root folder once in the script relinks everything.

Well we have deciced that for all parties would be better to use [getenv X] since project_directory is defined dynamically. This way outsorced worker without pype will only add one envVar into his system and all will work as if he had pype running. After he is finished he/she will send the nuke script for studio rendering and no need for remapping.

[jrsndl]

Well we have deciced that for all parties would be better to use [getenv X] since project_directory is defined dynamically. This way outsorced worker without pype will only add one envVar into his system and all will work as if he had pype running. After he is finished he/she will send the nuke script for studio rendering and no need for remapping.

Totally understand. Just asking if you do [getenv X] once for whole Nuke script and use project_directory in nuke root node for relative paths, or you put [getenv X] into every file knob in the nuke script. Result should be totally same, just potential relinking out of pipeline would be as easy as changing one project_directory path.

[mkolar]

resolved by #884