getavalon
Improve containerise arguments
Issue
When creating tools which load files without use of Avalon loader but want to support the use of the manager we are forced to create "fake context". The function only uses the context to pass the representation id in a list of attribute, value pairs.
Motivation
To improve transparency in the function and reduce the look ups.
Proposition
Instead of passing the context, pass the representation, maybe even the representation id, as argument.
This issue to me reads a bit unclear. :)
When creating tools which load files without use of Avalon loader but want to support the use of the manager we are forced to create "fake context".
This isn't entirely true just in itself. The function as its stands does allow you to pass a fully legit context and it is made to operate correctly under those circumstances.
The point you're trying to make is that it doesn't actually need the full context since it only uses the representation's id from the context which would make its usage in other areas easier, for example those where a full context isn't readily available.
An example would be where only a representation is available as data, like when you already know the representation from the database you want to load. You'd have to query for the full context before you could containerize, which would be redundant since it's not actually using it at all.
The point you're trying to make is that it doesn't actually need the full context since it only uses the representation's id from the context which would make its usage in other areas easier, for example those where a full context isn't readily available.
That makes sense.
What I'm looking for is the simplest possible interface between each of the pipeline functions, create, load, remove and update. At the moment, their interfaces are both different and too complex IMO.
To your suggestion; yes, we could just pass the ID. The only reason for not doing that is performance, but I think that's less important here as it isn't an operation that is done in a loop or one that takes long enough to prevent the user from doing any work.
As with any change to the API, suggestions in the form of PRs are great, ideally alongside their siblings and a hint on use so we can get a sense of how they work as a whole. The most important thing to keep in mind is backwards compatibility.
If we can reach a point where we could compose simple scripts to build a shot, then I think that would be really cool.
# Build it
load("someid1")
load("someid2")
connect(load("someid3"), load("someid4"))
rig = load("someid3")
publish()
update(rig)
load("someid5")
To your suggestion; yes, we could just pass the ID. The only reason for not doing that is performance,
Actually, since it's only ever using the id in this particular function containerize it wouldn't be a compromise on performance. It would only reduce the complexity of its arguments.
Other than that I'm with you. For load("someid") currently you'd still need to tell it how to load, as in with which loader you'd want to do that. But I understand this is just a little sample snippet. :)