Search Unity

  1. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice

Resolved packages-lock.json

Discussion in '2020.1 Beta' started by Hyp-X, Jun 15, 2020.

  1. Hyp-X

    Hyp-X

    Joined:
    Jun 24, 2015
    Posts:
    390
    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?
     
    jdw-creare, leni8ec, Peter77 and 2 others like this.
  2. rfadeev

    rfadeev

    Joined:
    Oct 1, 2013
    Posts:
    19
    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.
     
  3. Coroknight

    Coroknight

    Joined:
    Jul 10, 2012
    Posts:
    26
    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.
     
    phobos2077 and leni8ec like this.
  4. Hyp-X

    Hyp-X

    Joined:
    Jun 24, 2015
    Posts:
    390
    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.
     
  5. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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
     
  6. Hyp-X

    Hyp-X

    Joined:
    Jun 24, 2015
    Posts:
    390
    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.
     
    NibbleByteSSG likes this.
  7. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    616
    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.
     
  8. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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.
     
  9. fhamel_bhvr

    fhamel_bhvr

    Joined:
    Mar 24, 2015
    Posts:
    6
    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.
     
  10. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    238
    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.
     
  11. liamrharwood

    liamrharwood

    Joined:
    Jul 10, 2020
    Posts:
    1
    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.
     
  12. skwsk8

    skwsk8

    Joined:
    Jul 6, 2014
    Posts:
    32
    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
     
    HugoDidimo likes this.
  13. fhamel_bhvr

    fhamel_bhvr

    Joined:
    Mar 24, 2015
    Posts:
    6
    I just wanted to confirm that Unity was able to repro and fix this. The fix should be in 2019.4.10f1.
     
  14. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,294
    Ah, a good reason to update from 2019.4.8 to .10 once it's available ;-)
     
  15. fhamel_bhvr

    fhamel_bhvr

    Joined:
    Mar 24, 2015
    Posts:
    6
    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!
     
    NibbleByteSSG and sniffle63 like this.
  16. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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?
     
    florianveltman and Satoshi-Yoda like this.
  17. Satoshi-Yoda

    Satoshi-Yoda

    Joined:
    Nov 12, 2017
    Posts:
    2
    Yes, we also have this issue about com.unity.test-framework 1.1.3 vs 1.1.1
    Using Unity 2019.4.10f1.
     
    florianveltman likes this.
  18. florianveltman

    florianveltman

    Joined:
    Sep 7, 2012
    Posts:
    21
    We started having this exact same problem too, with Unity 2019.4.13f1
     
    Satoshi-Yoda and RedHatJef like this.
  19. RedHatJef

    RedHatJef

    Joined:
    Jun 11, 2019
    Posts:
    4
    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?
     
    Satoshi-Yoda likes this.
  20. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    616
    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.
     
  21. RedHatJef

    RedHatJef

    Joined:
    Jun 11, 2019
    Posts:
    4
    @Adrian I assume there's a bug open for this? If not...do we need to open one?
     
  22. Adrian

    Adrian

    Joined:
    Apr 5, 2008
    Posts:
    616
    @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.
     
  23. florianveltman

    florianveltman

    Joined:
    Sep 7, 2012
    Posts:
    21
    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 :oops:)). 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.
     
  24. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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.
     
  25. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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).
     
    Satoshi-Yoda likes this.
  26. Satoshi-Yoda

    Satoshi-Yoda

    Joined:
    Nov 12, 2017
    Posts:
    2
    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?
     
  27. NibbleByteSSG

    NibbleByteSSG

    Joined:
    Jan 7, 2020
    Posts:
    28
    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.
     
  28. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    468
    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?
     
unityunity