Peer Dependency?

Hi,

So I was running into an issue recently when I already have Post Processing Stack 2.0.10-preview installed via package manager. Then I want to install LWRP 2.0.8-preview which had a dependency on Post Processing Stack 2.0.8-preview.

LWRP 2.0.8 got installed but then conflicts with existing PPS 2.0.10, throwing errors like:




I am pretty sure LWRP doesn't depends on Post Processing Stack, so it looks like a case for peer dependency, how does Package Manager plan to resolve this kind of conflicts?

And more interestingly, the issue is resolved by uninstall PPS 2.0.10; after that, Post Processing still works in my project, so does it mean: LWRP comes with its own PPS (which is imported implicitly, not shown in Package list)?




My hope was Unity Package Manager will follow the npm package.json model, and have a flatten dependency tree in Packages folder.

But Unity didn't plan for different version of package to co-exist, so I am not sure how Unity would communicate this to users? Like you don't need to install PPS because LWRP comes with it's own preference?

(issue was previously discussed in LWRP thread)

 

The dependency listed for postprocessing in LWRP 2.0.8-preview was 2.0.8, not 2.0.9, when I tried this earlier today!

edited to add - I just tried removing LWRP 2.0.8 from my central package cache just in case something had got messed up, but the result is the same, the postprocessing dependency is 2.0.8 not 2.0.9.

Anyway I agree with the OP that the way this dependency stuff currently works could be confusing for some users and is not what some expect. To be honest it hasnt bothered me but thats probably because I already knew how it actually worked. And I'd agree that the fact these additional packages which are being used dont show up in the Packages part of the Project browser (that was added with 2018.2) is only going to increase the confusion and also poses a functionality limitation since we cant browse the contents of those packages within the editor (unless we also explicitly add the right versions of these packages via package manager UI or manual manifest editing).

 

Regarding it being 2.0.8 not 2.0.9 as a dependency, I looked around on github and it is 2.0.8 on the various recent 2018.2 github branches. Its version 3.0.0 of LWRP that has a post-processing dependency of 2.0.9.

 

Hi Tim, while I know Post Processing Stack 2.0.8-preview would work with LWRP 2.0.8-preview, this issue is larger.

- First of all, we can't assume the users know this beforehand, the package manager certainly have enough info to warn users about this or even resolve this by itself, but it didn't.

- Second, the cause of issue, as reported by another user in the LWRP thread, is because Post Processing Stack changed its assembly name on 2.0.9, likely to match LWRP 3.x-preview or Unity's internal requirement. This is a breaking change and we cannot reasonably expect users to resolve it.

- Third, the point of versioning and dependency management is to avoid breaking changes triggering cascading problems. and PPS' assembly name change is a good test!

There are certainly tons of issues I am not aware of that lead to current design, but I echo these suggestions:

- Semver can help, we would like to see Unity adopt something similar.

- When conflict resolution is too difficult, expose incompatibility warning in package manager.

- In Editor UI (the project view), Flatten packages or explicit list nested dependencies. As a reference, see nodejs and npm.

 

Yep, Package Manager in 2018.2 is heading in the right direction where all imported packages are now visible, this implicit dependency goes against that design ("implicit" in terms of package visibility, not the manifest file).

I would prefer Package Manager just help to import the right version of Post Processing Stack when it's indeed a dependency, and warn user against incompatibility when it failed to meet a peer dependency.

 

Even if there is no way this can be elegantly solved/made clearer at the moment for whatever reason, I would recommend that as an interim step something at least be put in the text descriptions of packages that show up in the Package Manger UI, to make clear what the dependencies are, and that they are being automatically referenced.