add library type to ContainersFilterResult

[vincentullmann]

Changelog Description

add library as another possible category in ContainersFilterResult

Additional info

filter_containers only knows about products from the given project_name.
this causes products imported from a library to be flagged as not_found.

Some hosts use the category to mark the loader nodes different. For example nuke uses them to apply different colors in the node graph. This PR would allow us to apply a different color to nodes reading from the library, rather than them being colored as not_found

Testing notes:

1. load a bunch of different products (a latest version, a non latest and one product from a library)
2. run this script (or similar):

from ayon_core.pipeline import registered_host, get_current_project_name
from ayon_core.pipeline.load import filter_containers
from ayon_core.pipeline.load import utils

host = registered_host()
project_name = get_current_project_name()
containers = host.get_containers()

filtered_containers = filter_containers(containers, project_name)
for category, containers in filtered_containers._asdict().items():
    print(category)
    for container in containers:
        print("\t{project_name}, {name}, {version}".format(**container))

Open Questions:

should we distinguish between library_latest and library_outdated?

for the sake of simplicity I decided not to

should we distinguish between library and from_other_project (products from another project where the source project is not a library)?

I think the not_found category covers this well enough for now. I can't think of a use case where users would pull in assets from another project that is not a library

[BigRoy]

I'd say this is straight up wrong.

If from a library, we should still check version status like any other.

What this should really be doing is check whether it's the latest taking into account the container's project name value to look it up in the right project. Personally to me the separate library category makes no sense to me.

Why is it being part of a library relevant to anything?

---

should we distinguish between library_latest and library_outdated?

for the sake of simplicity I decided not to

should we distinguish between library and from_other_project (products from another project where the source project is not a library)?

I think the not_found category covers this well enough for now. I can't think of a use case where users would pull in assets from another project that is not a library

Not at all, it's just a version - it just belongs to another project. When we check whether it's outdated, we should just check if the version is... regardless of where it comes from.

The bug is that we're not checking apparently across projects whether it is of the right version?

[iLLiCiTiT]

I don't understand why not allowed for library project deserver own category in filtered options? It is just not valid... If it should not be used for library project then it should probably override is_compatible_loader.

But technically we can "reference" from libary projects, but the loaders are not storing the project name to container data, which is probably what is causing the not_found issue.

I don't think we'll merge this PR, at least not in this state, we should rather focus on either fixing the loaders, or implement is_compatible_loader. Or just mark loader with simple bool if can be used for other projects than current project, but first look if adding project name to container data isn't all we need to do...

[vincentullmann]

Why is it being part of a library relevant to anything?

For us, a product belonging to another project vs. a project belonging to a library does have a different meaning.

If an artist loads in products from another regular project, that would be considered wrong.
The other project may get archived while they are still working on projectB. Or restoring projectB would also require projectA to be restored etc.

Loading products from a library however is a very valid workflow (for us at least).
Examples would be generic 2d elements such as smoke, fire, dust clips used in compositing. We don't want to copy these into each project that uses it, instead artists would be encouraged to load them directly from the library.

One example where I was planning to use this would , for different node colors in nuke: https://github.com/ynput/ayon-nuke/pull/278/changes#diff-2b72fd20b424aa2837f801f8df5ae6fca06e7ea79c0d6b852c0cc72f65eb56daR632-R636
So an artist can see if:

• read node loads from the current project = green if latest / orange if outdated
• read node loads from a library = purple (accepted workflow)
• read node loads from another project = not found / yellow (bad)

[vincentullmann]

How would you feel if we'd split into the following categories:

category	state	project	default node color	note
invalid	n/a	unknown	red	invalid metadata
not_found	n/a	unknown	yellow	missing entity in database
latest	latest version	current project	green	good!
outdated	current project outdated versions	current project	orange	update me!
library_latest	latest	a library project	light purple	good
library_outdated	outdated	a library project	dark purple	update me
other_project_latest	latest	other projects	light red	bad
other_project_outdated	outdated	other projects	dark red	very bad

if studio's want to they could set the colors of library_latest = latest; library_outdated=outdated match them with the other_project_* variants. or make them all green/orange

[BigRoy]

How would you feel if we'd split into the following categories:

To me that's worse.

The 'best' case is we just add the 'library' category, but admittedly - it's so overly specific that I really doubt we'd even add it. But preferably we don't go 'spreading out the categories'. Something is either latest, or not, or not found, etc.

Want to know whether the container is of a different project? Use project_name from the container itself. I don't think it's up to filter_containers to return that admittedly.

We're also not listing whether the container repre has tags, or the statuses -etc. ;) I feel like if you want more info, you'd need to query it for whatever use case you have.

[vincentullmann]

I've updated ynput/ayon-nuke#278 so that

• filter_containers is expected to only return the 4 original categories: latest, outdated, invalid and not_found => making this PR redundant
• the Loader(Base)Class implements the logic to compare both: category and the containers project_name to determine the final node color

I'm not 100% convinced yet that this the best way, as we'd likely have to reimplement the _is_library_project and is_other_project each time we want to differentiate between them. I have an Idea how we might be able to resolve that, but I'd need to mock that up as a draft first to see if it actually works out.

[iLLiCiTiT]

In my opinion you don't need _is_library_project you just have to check if project_name is filled and if the value is same or different from current project.

I think filter_containers still needs modification to check if project_name is filled on container, which would change how the logic goes (which is actually a TODO in the function docstring).

[iLLiCiTiT]

PR to respect container's project name #1909 .