getavalon / core

The safe post-production pipeline - https://getavalon.github.io/2.0
MIT License
218 stars 49 forks source link

Dependency Tracking #129

Open mottosso opened 7 years ago

mottosso commented 7 years ago

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 containing sh050, because sh050 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.

MyApp
Framework==0.9.4
Library>=0.2

It then downloads these dependencies and looks at what dependencies the dependencies has.

MyDependency
OtherFramework==0.1.2
OtherLibrary>=0.0.4

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.

MyAsset
OtherAsset=v023
OtherAsset2=v102
BigRoy commented 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.

mottosso commented 7 years ago

That's a good point.