Perforce Addon

Development
,
1

Hey - I will soon be at a point at my studio where I will be getting Ayon setup and rolled out. This requires a Perforce integration. I had already done an integration for OpenPype:

The issue is it required heavy modification to the core of OpenPype to work, ie it didn’t just sit on top of OpenPype like a standard plugin, it modified how the internals worked.

Here are some key areas that required exposure, as an example of how deep I had to go (note that the design provided an interface for any version control system, we were just using Perforce):

  • Workfile path resolution.
    Added a file sync call to pre_add_last_workfile_arg.py to make sure the local workfile path was up to date.

  • DCC file IO hooks
    Added function pre-load that would sync the correct Perforce revision for each asset in the scene.
    This required data to be stored with each version in the database.
    Added function pre-save that would check the local file out, allowing it to actually be saved.
    Added function post-save that added the file to a changelist for later submition.

  • Publish plugins
    Created a sub-class of FileTransaction that overwrote the process method that would process the file transactions using Perforce instead.
    Created an integrate_version_control.py plugin for pyblish that would submit the published files to Perforce and then update OpenPype with the submitted changelist numbers.

  • Sub-classed a lot of widgets and models to manage and expose Perforce functionality to users.

I have thought a lot about how the next iteration of this would go in an ideal world.
Instead of having to add Perforce specific commands to the core, the core would provide mechanisms that allowed for plugins to override specific pieces of functionality as well as providing events/hooks around DCC file operations allowing for plugins to intercept and run actions such as syncing file versions or adding files.

It would also be ideal if there was a way to register different widgets that a plugin would define with a design more relevant to the plugins functionality.

Now I haven’t dug deep into the code since OpenPype 3.14 so some of this may already exist, but I would like to feel out how likely these sort of changes would be merged into the core as I would prefer to not have a completely divergent code base.

2

I would love to have this working.

Although we use perforce strictly for our unreal scenes and can work separately from ayon it would be a amazing addition.

3

@munkybutt would love your input on GitHub - ynput/ayon-version-control if you havent already looked at it.

4

@tokestuartjepsen - that is great! This makes me getting re-started a lot easier.
Initially I was put off by the idea of a REST api to communicate with an external server to send the commands, but if it works then good enough :smiley: - My plan to work around this was to write P4Python resolution logic that would download the correct backend lazily.

Otherwise I have refactored the perforce backend to remove dependencies on qt and make it more performant. I am in the process of getting my studio to sort out a policy for Open Source contributions so hopefully I can add a PR with the changes.

For this api to work effectively though, it would need the various changes to core that I mentioned.

5

Tagging @Petr_Kalis for visibility