Open mottosso opened 7 years ago
Just adding a note, theoretically an asset could rely on two different versions of the same asset. (Having them both linked)
Also, I believe the published versions are totally encapsulated and as such the two should never conflict ever. As such dependency conflict should (theoretically) not happen.
That's a good point.
Goal
Enable sharing of one asset that includes references to other assets.
Motivation
Imagine an artist working remotely on
sh050
. He'll need access to files related to the project, but not all of them. And we can't just send the directory containingsh050
, becausesh050
depends on other assets from elsewhere, depending on the artist role.Implementation
Tracking of dependencies is a well versed subject of research and application. There are lots and lots of implementations of it out there in the wild.
To name just a few.
Each of them tackle the same issue, in slightly different ways and for slightly different purposes. The purpose of their individual existence is I think best illustrated by this simple fact: we can't use any of them.
The reason we can't use them is because because they do both (1) dependency resolution and (2) downloading of data and the data we need isn't what they offer.
The dependency resolution aspect, though different across each of them, are conceptually sound and what I'm thinking is we pick one of these and re-implement the dependency resolution into our own dependency tracking mechanism.
pip
Pip operates on perhaps the most simple of rules. Given a library, it looks at what the library depends on.
It then downloads these dependencies and looks at what dependencies the dependencies has.
So on and so forth, recursively pulling dependencies until there is no dependency left.
The other alternative is the likes of Rez, which not only looks downstream for dependencies, but upstream as well to determine whether a child-dependency conflicts with some other dependency.
Something along the lines of
pip
could suffice for us.