Hi! As of right now we can’t afford to have duplicate versions of working files and publishing files.
So I’m looking for advice to find the best workflow to publish in place? Moving the files instead of copying is also a problem because of the network bandwidth used for that purpose.
My ideal workflow will be to publish the files in place and after the publish change permissions for the publishing files so no one can edit them.
What will happen when the work file template finds, published working files, and regular working files in the same location?
Will I need to fork to many apps?
Thanks a lot in advance! any suggestions are helpful
2 Likes
Hi Macbeth,
Thanks for reaching us. I think you could use multi-root to solve the problem.
The primary is the published files. The secondary could be your working folder which is point to artist workstation. Or reversed.
You need keep each artist use the same local path for their working file. And another inconvenient is they can’t share workstation. 
Hope this is helpful.
Loney
2 Likes
Hi thanks a lot! Sounds good!
Sorry but I don’t understand why they won’t be able to share workstations? Not been able to do this would be an issue as we constantly share machines.
So the idea of using the same location for working and publishing files is not possible?
Thanks a lot in advance!
Just can’t share working file. Published file is on a shared storage. It is ok.
Because, the working file is on artist’s personal workstation. If they change to another workstation, they can’t access the original one. They have to use one workstation to finish all his task.
Does it make sense?
Loney
2 Likes
Yes it does. We can’t use that option, also will be hard to configure the farm for that workflow.
: (
Using the same location for working and publishing files is not possible?
Thanks a lot in advance!
sorry but I don’t think this is solving his question and could create more trouble.
We publish in place and it’s totally possible!
You just need to take over the collector hook and make sure to set the following properties to both have the filepath you want to publish.
item.properties[“path”] = filepath_to_your_frames
item.properties[“publish_path”] = filepath_to_your_frames
This should skip the copy/move and works.
You could then write some python logic that set’s the file’s properties to “read-only” so they can’t be overwritten.
We used to move files to publish location, you could also do that by adjusting the publish_file hook to use shutil.move instead of shutil.copy2.
Moving to the same network share will be very quick as it’s not actually copying the data but just moving the filesystem pointers.
Hope this helps!
5 Likes
just to piggyback on this about your template question;
You can definitely use the same template for multiple purposes, so you would also want to set your publish_template the same as your work_template in your case so your one path will validate for both
if using config-default:
. You can change that on the config/.ymls example: shot_step.yml under your tk-multi-publish inside the tk-{application} sections.
its called template_publish and template_work
if using config-default2
you would change it in the tk-multi-publish.yml or tk-multi-publish2.yml inside the settings folder inside config/env/includes. Then just point primary_publish_template, and the template_work to the same template. if using multi-publish2 looks like its called work_template, and publish_template
just make sure you comment out the old publish_template, and work_template i would probably make a new template with a new name just for organization sake, since you are changing the default pipeline.
if you leave those templates and alter them to be the same you will get errors saying two templates match the incoming path, so in your case you will need to collapse down to just using 1 template for both work and publish.
-Ross
3 Likes
Ah yes that may be an easier way actually!
1 Like
Thanks a lot for your info ! Just one question.
Wouldn’t I have to modify tk-multi-workfiles2 also?
yep yep any app that uses the work_template or publish_template from a primary publish would need to be changed;
tk-multi-workfiles/tk-multi-workfiles2
tk-loader / tk-loader2
you’d want to do a change like this in a sandbox pipeline config, and make sure you hit all the apps before pushing to your stable config for sure, its a big pipeline change, but seems necessary for your space limitations.
1 Like
Hi @Ross_Macaluso just try it today but seems that it won’t be possible just using one template for work and publish, when publishing shutil will complain that you are trying to copy the same file.
So seems there is no other way than @Ricardo_Musch suggestion of Modifying the publish_file.py hook?
Or do I need to do both things?
Thanks a lot for your help guys!
EDIT:
Apparently this is a behavior exclusive for Linux, so I’ll have to modify the hook too, seems than windows shutil won’t complain about it?
I think you’ll have to use my suggestion.
If it still complains you may have to clear the item.properties[“work_template”] and item.properties[“publish_template”] keys.
So set those to “None” I guess.
I am not 100% clear on this.
What we have is our own collector which fills in the item properties for “publish_name”, “publish_version”, “path”, “publish_path” etc so that the publish_file hook from the publisher app itself can takeover and publish.
1 Like