User Environment Plugin

[davidlatwe]

Feature Propose

Allzpark allows user to inject environment change on Rez resolved context with it's environment editor widget, this is good for e.g. input VFX asset/shot name into the production pipeline context when required. However the widget is basically a plain text editor, so it's not really convenient for artist to use in their daily work.

So I propose to let Allzpark be able to accept custom widget e.g. Avalon mini launcher, and give that widget the ability to read/write/validate the user environment editor content.

Implementation

The custom widget can be loaded from allzparkconfig.py, e.g.

# allzparkconfig.py
def user_environment_plugin():
    from pipeline import tool
    return tool.AllzparkPlugin

Once it's been collected, Allzpark should validate the required signals and slots, e.g. :

• on_launched, a slot that will be called right before launching the application, Rez resolved env and the user env will be given. This gives the chance to validate the context.
• userEnvValidated, a signal for emitting the validation result, stop application launch if any message being emitted and log the message into Allzpark console.
• userEnvChanged, a signal for emitting user environment key-value pairs from widget in one batch. This will not overwrite but update the content of Allzpark's user environment editor.
• on_profile_changed, a slot that will be called on profile change. May give widget the ability to adopt current selected profile.
• userEnvReset, a signal for wipe out user environment editor.

Then the widget will be added into one additional dock widget and present on the GUI header, next to the profiles toggle button.

One environment plugin per Allzpark config should be enough.

What do you think ?

[mottosso]

Thanks @davidlatwe, that's an interesting idea.

That editor though, is really only meant for development of packages and not really something for users to manage. It circumvents the safety you get from authoring packages, since you now never know - as the developer - what the environment on your users machines actually look like.

What was it that motivated this feature? Does your packages not provide you - the developer - with enough control? What is it the artists are expected to add to the environment, on-top of the environment created by your Rez packages?

[davidlatwe]

Thanks for the questions :D

Does your packages not provide you - the developer - with enough control ?

Hmmm, or should say Allzpark does not provide the full ability of what we could do in command-line interface with Rez. Take application launching for example, we can set arguments to the tool that is being provided in context :

> rez-env package_a package_b -- app arg1 arg2

But Allzpark currently doesn't have that interface for user to set arbitrary arguments when launching the tool, so it could only do like :

> rez-env package_a package_b -- app

So I think the lacking of additional arguments setup widget is the true essence of this issue.

[mottosso]

Ok, but take me through the usecase from the point of view of the user, say an animator.

1. Animator arrives at work
2. Boots up machine
3. Starts Allzpark
4. Runs Maya to work on a shot

At which point, and for what purpose, would the user be interested in environment variables (if they even know what that is) and command-line arguments? :O Allzpark is ultimately the front-end for the clueless user, Rez and its command-line interface is for the developer. What am I missing here?

[davidlatwe]

In step 4, artist actually pick a shot number before or after launch Maya. And if it happens "before", then we can say the shot number is actually the argument that put into Maya or the pipeline tool that is waiting that input inside Maya, right ?

I didn't mean to let artist to know anything about the environment variables, instead I'd like artist to press buttons (like an asset/shot list) which will trigger the environment variable or the argument setup secretly, and put them into App like Maya. Allzpark's environment editor is just the middleman, for debug purpose mostly in my scenario.

[BigRoy]

Are you trying to add the Avalon asset widget into Allzpark as its own widget? So that whenever you launch the application it will additionally set the AVALON_ASSET and task etc. That's neat!

You are using the Validate return message to display something like: "Pick an asset and task to enable launching applications". Right?

This definitely seems clever!

[davidlatwe]

Are you trying to add the Avalon asset widget into Allzpark as its own widget?

Yep, that's one of my goals that I am trying to get from this proposal. Ultimately, I'd like to have this custom widget to give user more options then just luanching the tool which is being selected. And that custom widget may could do that by adding environment variables, or assembling command-line arguments.

You are using the Validate return message to display something like: "Pick an asset and task to enable launching applications". Right?

Yes :D

[mottosso]

Ah, you want to be able to pick the shot from Allzpark. Seems like a good idea.. but do we need to sacrifice the Environment Editor for it? Seems like something we could add regardless, like a user-definable dockable widget that has access to the UI and environment on its own?

[davidlatwe]

Seems like something we could add regardless, like a user-definable dockable widget that has access to the UI

That's almost what I am after ! :D

and environment on its own?

So you mean, there would be three environment variable sets, one is Rez resolved, one is User Env, and the third is coming from this plugin ?

I am not sure, since I think the custom widget will not be allowed to replace the User Env, but only dict.update it. So should be safe to share that space, I think.

[davidlatwe]

and environment on its own?

In fact, I think I'll try to separate them first and see how it goes. I am working on a draft implementation now. 🚀