Question Unity Package Manager packages-lock.json differs between computers.

I am working on a project with multiple contributors and for some reason our packages-lock.json files differ even with the same setup in the UI.
We have the Rider Editor extension installed which depends on the Unity Test Framework package.

On my computer the relevant part of the packages-lock.json file looks like this:

Code (JavaScript):

1.     "com.unity.ide.rider": {
2.       "version": "1.1.4",
3.       "depth": 0,
4.       "source": "registry",
5.       "dependencies": {
6.         "com.unity.test-framework": "1.1.1"
7.       },
8.       "url": "https://packages.unity.com"
9.     },

But on my contributor's computer, they get a different version of the test framework in the dependencies section.

"com.unity.test-framework": "1.1.3"

If I change my file by hand to say 1.1.3, when I go back to unity, it sets it back to 1.1.1
And for my contributor it does the opposite, always setting it to 1.1.3

I've made sure my package manager list is up to date.

Has anyone experienced something similar?

 

@okcompute_unity logged one:
CaseID: 1268778

 

@skwsk8 Where did this end up?

 

I'm experiencing this as well, with those two specific versions of the same package.

 

Just updated; will edit this comment when I get a chance to check.

EDIT: Unfortunately the issue seems to persist. Both computers are running the project in 2019.4.19f1 (the latest LTS).

 

Well... technically the real solution is to not include package crud the user isn't necessarily going to be using, such as Rider IDE or collaborate or purchasing or analytics or Timeline or Cinemachine or ANY of that other crud.

I've done a few of the Unity "complete project" packages lately and they are actually un-doable because of errors in the crud imported above.

Two possibilities:

1. the user is a noob in which case he doesn't need any of that, and the errors it generates block him 100% and he ends up here. Don't do that.

2. the user is an expert in which case it takes him 2 seconds to add it himself.

Otherwise it's just an infuriating tax on my every time I spin up a fresh project, which can be multiple times a day when testing and iterating in a multi-project production environment.

Not only that, the package manager can only remove ONE junk package at a time, making me have to wait 10-20 seconds between EACH PACKAGE before I can remove the next one. MADDENING!

Solution: I close Unity, I edit my manifest and wipe out all the crud... every single time I make a project!

 

@okcompute_unity this appears to have worked, but yeah, seems like it would be best to include a minimal set of packages in the editor.

EDIT: Also, for some reason, I don't get emails when this thread is replied to, how do I change that?

 

It simply should not be permitted for a package two exist in two variants but with the exact same version number. This includes any changes to the package manifest; a change to the manifest is a change to the package!
While it might not be possible to enforce this in every scenario with the existing packages-lock.json, it should at least be done for the central repository at packages.unity.com. As a next step, the system could store appropriate checksums in the packages-lock.json to prevent invalid/accidental changes also when working with e.g. a local package repository.

The current situation is an absolute nightmare. I'm working on medical software. Imagine the joy of explaining to an external auditor that the software might change its behaviour without anyone noticing.