Skip to content
This repository has been archived by the owner on Sep 20, 2024. It is now read-only.

Store typed version dependencies for workfiles #2192

Merged

Conversation

davidlatwe
Copy link
Contributor

@davidlatwe davidlatwe commented Oct 31, 2021

This PR is the first step for #2092 .

There are two types of links that will be created in this PR:

  1. scene loaded versions -> workfile (reference type link)
  2. workfile -> publishing instances (generative type link)

For linking specific loaded versions as direct dependencies to the publishing instance (e.g. specific rig to a pointcache), that would require a few more host specific PRs.

And for those future implementations, any active Pyblish plugin that sets/extends list of dependencies version ids into instance.data['inputVersions'] will be handled by the new plugin IntegrateInputLinks in this PR.

TODO

  • Visulize those workfile centric links in Workfile Loader App. (displaying what version of subsets has been used in scene)

@tokejepsen
Copy link
Member

I know this is specific to versions but for assets we are using inputs; https://github.com/pypeclub/OpenPype/blob/develop/openpype/plugins/publish/extract_hierarchy_avalon.py#L59

@davidlatwe
Copy link
Contributor Author

No worries, we have that covered. We use inputLinks :D

@davidlatwe
Copy link
Contributor Author

So I find the Workfile App isn't a good place for showing the dependencies that relates to the workfile, since the workfiles over there aren't the published ones so the link infomation could be easily outdated.

How about this, a simple widget that can be embedded in the Loader or elsewhere ?

image

The above snapshot is where I am at the moment. As you can see, the list could be really long if we list every links in there. I am thinking maybe we could just displaying asset + family and the count ?

And if more detailed info is required, right click to show a context menu for further action, the action would maybe depends on Apps. For example, the Loader App could take those input/output version ids from the dependency widget and only show all those versions in the subset view.

@davidlatwe davidlatwe marked this pull request as ready for review November 7, 2021 19:15
@mkolar
Copy link
Member

mkolar commented Nov 17, 2021

Task linked: OP-1707 publish incoming and outgoing links

@antirotor
Copy link
Member

As I've tested it works really well. I am wondering if we should add option to open workfile in Dependency links in another process. So if you find what workfile was used to publish subset you are interested in, you could double-click on it and new Maya (for example) in the right context will fire up with that workfile opened?

@mkolar mkolar added the type: feature Larger, user affecting changes and completely new things label Nov 18, 2021
@davidlatwe
Copy link
Contributor Author

I am wondering if we should add option to open workfile...

Hmmm, or open up Workfile App and select the right workfile automatically ?

And how about the tiny widget that embedded in the Loader (image above) ? Any feedback on that ?

Copy link
Member

@mkolar mkolar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is working really well for the first iteration. I would actually leave it as is and work on using those links and better GUIs in further PRs. This is about publishing workfile links and that is being done very well.

@davidlatwe
Copy link
Contributor Author

Sorry, forgot to fix what @iLLiCiTiT has mentioned in his review, now should be ready !

@mkolar
Copy link
Member

mkolar commented Nov 24, 2021

Happy to merge

@mkolar mkolar changed the title Typed asset version dependencies: Workfile centric links Store typed version dependencies for workfiles Nov 24, 2021
@mkolar mkolar merged commit a8f2e0f into ynput:develop Nov 24, 2021
@davidlatwe davidlatwe deleted the feature/typed_asset_version_dependencies branch November 24, 2021 19:43
@mkolar mkolar mentioned this pull request Apr 29, 2022
3 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature Larger, user affecting changes and completely new things
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants