Replace toml files

[tokejepsen]

This is a work-in-progress PR. Not ready to be merged!

This is an effort to implement #50

[tokejepsen]

This currently depends on getting https://github.com/getavalon/launcher/pull/36 merged.

[mottosso]

Could you elaborate a bit on what this PR is for? Which TOML files are you replacing, and why? Is it the file format specifically you are removing, or the data inside of them?

[tokejepsen]

It is the TOML files here.

I have outlined the issue in #50, but essentially it's about reducing the amount of files.

The data from those files are being preserved as actions.

[mottosso]

Ok, just to make sure we're on the same side regarding the purpose of those files.

Firstly, they aren't meant to be included in the Avalon distribution. avalon/setup had them, as a sort of "starter pack". But I don't think we should bundle every application under the sun. Partly because it'd be a lot of files, but also because I think we should encourage custom files, fit for production.

For example, at Weta they may use a version of Maya including a ton of custom plug-ins. Maya just isn't Maya without them, in which case it's safe to associate their version of Maya with them in the form of a definition.

Then there are applications which aren't off the shelf, like any bespoke tools (including our project manager) which have environments of their own, but launch like any application.

Maybe having made the manager into an action is what diluted this idea; perhaps we should instead make that a (bundled) application definition.

Secondly, the reason for the corresponding .bat file for each application definition, is such that the definition can avoid explicitly pointing to a OS-specific path. The definition can instead make reference by name, e.g. maya, and let a .bat file (or whatever executable you use) reside on PATH; cross-platform.

Perhaps the explosion of definitions (i.e. one for every version of Maya) is part of the problem; they are likely to require the same information, with just a small tweak on the inside. Perhaps the way forward with those is instead to parameterise some keywords, like the executable name, such that it can be passed to it via the launcher or some other mechanism. To go from 10 Maya definitions, to 1.

Anyway, with this in mind, do you still feel that these definitions should be actions?

[mottosso]

Oh and one more important point; the definitions aren't necessarily global, but can be per project. They reside on the users PATH, so whichever definitions are there are the ones used by Avalon.

[tokejepsen]

Think I need to outline what this PR looks like implemented.

If a project configs app has a regex pattern then that will be matched against the available actions. Example:

[[apps]]
name = "nuke"
regex = "Nuke[0-9]+.[0-9]v[0-9]"

This will match all Nuke executable (this actually also includes NukeX, NukeAssist, NukeStudio, Hiero and HieroPlayer) versions.

[[apps]]
name = "nuke"
regex = "Nuke10.5v[0-9]"

This will match all Nuke10.5 versions, so newer patches are allowed to be launched.

[[apps]]
name = "nuke"
regex = "Nuke10.5v7"

This will only allow Nuke10.5v7 to be launched.

Since Nuke is a little bit of a special beast when it comes to having multiple applications within the same executable, so when only specifying "Nuke" on a project you will be able to launch the whole Nuke family. To this I would say that people know what application they want to use. The issue is they don't know which versions are allowed on a project.

Firstly, they aren't meant to be included in the Avalon distribution. avalon/setup had them, as a sort of "starter pack". But I don't think we should bundle every application under the sun. Partly because it'd be a lot of files, but also because I think we should encourage custom files, fit for production.

Since this project is about making the entry-point to Avalon easier, I think we should include an optional "starter pack". Advanced users should be able to disable it easily though as well.

For example, at Weta they may use a version of Maya including a ton of custom plug-ins. Maya just isn't Maya without them, in which case it's safe to associate their version of Maya with them in the form of a definition.

Big production houses will customize but will also have people to look into customization. This is not the case for small or mid sized companies, which I think will be Avalons target market.

Secondly, the reason for the corresponding .bat file for each application definition, is such that the definition can avoid explicitly pointing to a OS-specific path. The definition can instead make reference by name, e.g. maya, and let a .bat file (or whatever executable you use) reside on PATH; cross-platform.

As we are pointing to the OS specific applications anyways in the bat/sh files, we don't really win anything. With these actions you could argue that it only accommodates for the standard installation of the applications. In the case of having custom installations, I think the user is advanced enough to customize these actions. Maybe even subclass them.

Perhaps the explosion of definitions (i.e. one for every version of Maya) is part of the problem; they are likely to require the same information, with just a small tweak on the inside. Perhaps the way forward with those is instead to parameterise some keywords, like the executable name, such that it can be passed to it via the launcher or some other mechanism. To go from 10 Maya definitions, to 1.

Yeah. This PR is my suggestion of how to tackle this.

[tokejepsen]

This PR is dead, closing.