Chore: Use project name from context to get settings

[iLLiCiTiT]

Changelog Description

Use "projectName" value to get settings instead of get_current_project_settings.

Additional info

This is technical change, we should make sure the project which is set in context is used as source of truth for publishing.

Testing notes:

1. Settings are collected as before.

[BigRoy]

The setting of context.data["projectName"] here happens in an if statement that doesn't seem all too promising that we can rely on the project name being accessible.

Same goes for the logic here.

Should that if statement be removed as well?

Testing of this PR should likely need 'special testing' in hosts that still use the legacy publisher since it would go through slightly different logic.

[iLLiCiTiT]

The setting of context.data["projectName"] here happens in an if statement that doesn't seem all too promising that we can rely on the project name being accessible.

Not sure what to do with this, maybe just use .get(...)?

Should that if statement be removed as well?

Which if statement?

[BigRoy]

Which if statement?

The if project_name statements in the code I linked.

ayon-core/client/ayon_core/plugins/publish/collect_from_create_context.py

Lines 36 to 38 in f598017

	project_name = create_context.get_current_project_name()
	if project_name:
	context.data["projectName"] = project_name

ayon-core/client/ayon_core/plugins/publish/collect_current_context.py

Lines 28 to 29 in 2072f2f

	if not project_name:
	context.data["projectName"] = current_context["project_name"]

Both seem to 'hint' that context.data["projectName"] MAY not exist.

[iLLiCiTiT]

Both seem to 'hint' that context.data["projectName"] MAY not exis

Yes, I'm asking how to handle that in this plugin. I won't touch the other plugins.

[BigRoy]

Yes, I'm asking how to handle that in this plugin. I won't touch the other plugins.

Ah good question - it seems like we always expected a project name to be 'retrievable' and thus be valid - so I'd actually say we should just make those always being set in the other plug-ins accordingly. Rather prefer that, then now still adding a get_current_project_entity fallback in this plug-in.

[iLLiCiTiT]

it seems like we always expected a project name to be 'retrievable' and thus be valid - so I'd actually say we should just make those always being set in the other plug-ins accordingly.

You can have completelly different logic in custom addon which collects "projectName". So I don't think we should enforce it.

Rather prefer that, then now still adding a get_current_project_entity fallback in this plug-in.

I don't think that is correct behavior. Using current project settings would be against what is inside publish context...

All other plugins are expecting the project is set, it would crash much sooner than in this plugin, and I don't think we should try to handle that case to be honest.

[kalisp]

Tried a couple of DCCs, didnt explode.