Resolved packages-lock.json

Hi,

I noticed that a file called Packages/packages-lock.json is started to appear in the latest version of Unity 2020.1.0b12

Should I
1.) Check in this file to source control to share it with the team?
2.) Add to .gitignore / .svnignore / whatever to avoid checking it in?

 

Hi,

After playing around with Unity 2020.1.0b12 and custom packages, I see that custom packages added to Packages/manifest.json via git url now add lock information (like hash) not to Packages/manifest.json like before but to Packages/packages-lock.json instead.

This means that Packages/packages-lock.json file should be added to your version control system of choice.

 

I would highly recommend checking in the lock file. This will help your team stay on the same versions of packages across machines and reduce "it works on my machine" type problems.

 

Thanks, I thought that I need to check it in, because otherwise it would be in Library
I still think that the name is somewhat misleading.

 

We have actually added it to our SVN ignore list, because we had some issues with it.

There is this section in it:

Code (CSharp):

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

This is copied from my PC, but on some machines, this keeps changing the version on this line to 1.1.3:

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

Me and other programmers have Rider installed the line says 1.1.1. The others I observed having this issue don't have one installed. Keep in mind that the manifest.json is always the same.
Changing it manually to any version leads to nothing as the file gets regenerated instantly when you focus Unity.
This behavior is weird for a lock file if Unity keeps regenerating it every time, so it is pointless to commit.

However, if you import packages from github the situation changes. Example:

Code (CSharp):

1.  
2. manifest.json:
3.   "dependencies": {
4.     "com.unity.package-manager-ui": "2.0.8",
5.     "some.random.package": "https://github.com/Whatever/CoolPlugin.git#upm",
6.     ....
7.   },
8.  
9. packages-lock.json:
10.   "lock": {
11.     "some.random.package": {
12.       "hash": "8329833d4cef27afb1e4665ef17b12a7a05bdf4e",
13.       "revision": "upm"
14.     }
15.   }
16.  

Github entries just keep a hash of what was downloaded at the time it was added. I'm not sure if this hash even represents the github specific revision. I.e. if you delete the cache files, will it download that specific revision it started it or the latest. If you want to get the latest version of the package, just delete the lock and Unity will re-download everything and re-generate the lock.
In this case this behaves as a lock that needs to be committed.

We don't have github plugins so we chose to ignore it for now.

Using Unity 2019.4.1f

 

That's just great.
Half of our team have Rider installed the other half don't.
But I cannot walk to their computers to check if this file is modified because we still work from home (covid...)
They might even found it but ignored it or put it in chat, but got lost in the noise there.

We also use different versions:
Unity 2020.1.0b13 and com.unity.ide.rider 1.2.1

I agree that it's not really clear what this "lock" file tries to achieve or if it succeeds in doing so.

 

Lock files are for making your setup reproducible. Ideally, if anyone checks out a project from version control, they should end up with the exact same code and assets. With packages, this becomes more complicated, because dependencies of a selected package might be resolved differently or because git packages aren't linked to specific commits. The lock file is there to make sure all dependencies get resolved the same way and the same commit is used for git packages.

Assume your project breaks because some dependencies changed but you don't know which. You know the project worked fine a week before. Without a lock file, you'd check out the project from a week ago but you'd likely end up with the same broken dependencies. With the lock file, you should get all the dependencies from a week ago and a working project, allowing you to track down the change that broke it.

Of course, the lock file shouldn't randomly change and I encourage you to file a bug with Unity.

 

Indeed this smells like a bug, but I don't have the time to report (or investigate) it right now. Maybe in a week or so. In the mean time, I'm interested if @Hyp-X or someone else has similar problems with Rider dependencies. I'm not 100% sure that it happens only on people that have Rider.

 

We have the exact same problem, @NibbleByteSSG - 1.1.1 vs 1.1.3 for the com.unity.test-framework dependency under com.unity.ide.rider - and nobody uses Rider on our team.

I was unable to find an open issue report for this. I will chase this up through enterprise support and report back.

 

Lol, it's not like UT invented this name. It's an industry standard and so should've been present from day 1. Most package management systems have those. So yeah, they should be under version control.

 

We also have the problem of 1.1.1 vs 1.1.3 for the com.unity.test-framework dependency under com.unity.ide.rider. None of us are using rider.

It also seems as though there isn't actually a 1.1.3 for Unit Test Framework? As far as I can tell, it only goes up to 1.1.14.

 

We have some people that get this same issue in 2019.4.6f1 the LTS release. Couldn't find a bug, so logged one: CaseID: 1268778

 

I just wanted to confirm that Unity was able to repro and fix this. The fix should be in 2019.4.10f1.

 

Ah, a good reason to update from 2019.4.8 to .10 once it's available ;-)

 

Support has confirmed that this fix shipped in 2019.4.10f1:

https://unity3d.com/unity/whats-new/2019.4.10

There is also a resolution note to consider:

Hope this helps!

 

Well, this didn't last long. We're using 2019.4.10f for more than a month now and it just started happening again. Same issue with com.unity.test-framework going from 1.1.3 to 1.1.1. Happens on people using Rider and VS. Happens on artists that don't use anything. Does anyone else still has this issue? Should I just commit 1.1.1. and will it stay that way?

 

Yes, we also have this issue about com.unity.test-framework 1.1.3 vs 1.1.1
Using Unity 2019.4.10f1.

 

We started having this exact same problem too, with Unity 2019.4.13f1

 

This thread is marked as "RESOLVED" - but seems like some folks (including us) are still seeing this. Any way to un-resolve the thread or do we need to start a new one?

 

The forum is not an official place to track issues and the "Resolved" tag is only informal. The preferred route is to report bugs via the bug reporter in Unity. You can then post the case number here or in a new thread, which might get the report into the right hands more quickly.

 

@Adrian I assume there's a bug open for this? If not...do we need to open one?

 

@RedHatJef A fix shipped in 2019.4.10, so I assume the original bug is closed. It's either a regression or the original bug wasn't fixed properly. The bug tracker isn't public, so your only option is to submit a new bug. This is encouraged by Unity, they use duplicate bugs to gauge the prevalence of issues.

 

I haven't had a chance to look into the 2019.4.14f1 release regarding this bug (we're just ignoring it for now as it's not a great time to set up a dummy project and submit a bug report (though when is it ever a good time to do so )). Has anyone encountered the bug in this new 2019.4.14f1 release?
Going through the release notes I can't find anything related to this bug, but I thought I'd ask here anyhow.

 

It seems that it was 1.1.3 before (when fixed) and now it wants to be 1.1.1 for all PCs in our office. So it may be ok as long as it is consistent between users. Do you know any inconsistencies between yours as we don't seem to have one. We've committed the change and don't have issues with it for now.

 

Ok, I take my post back. It produces different values on different machines. I'll burn this file and never want to see it again (in the source control).

 

I definitely have this issue with the same version but different machines.

Is it safe to exclude this file from source control? Or it can raise issues when someone will try to open project on "fresh" machine without this file?

 

I believe it is safe, because Unity regenerates it every time from the packages.json. As mentioned above, it is useful only when referencing packages directly from git.

 

The problem I'm having is that Unity will auto-add this file back to perforce when it generates/downloads new packages. Due to perforce's weak ignore behavior if you add a file even if ignored it will add it to the changelist and then this file starts causing problems again. Anyone else have a workaround for this for people that use the source control plugin in Unity?