Enable repeatable package restores using a lock file

[anangaur]

• Status: Incubation
• Spec: Enable repeatable package restore using lock file for PackageReference based projects

Discussions should happen on this issue. Please link other issues with similar asks to this one.

July 2018 - Announced feature
December 2018 - Blog

[bording]

It appears that the current specification document is incorrect regarding how version ranges work with direct dependencies. It says that given the following package reference:

<PackageReference Include="My.Sample.Lib" Version="[4.0.0, 5.0.0]"/>

That it would pick the highest version, 5.0.0. This is not what I observe. Instead, that version range would resolve to the lowest version, 4.0.0.

Floating version numbers appear to be the only case where any sort of highest version logic is applied.

I also don't see anything indicating that highest would be expected in any of the documentation I've found:

https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution
https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

[anangaur]

Thanks @bording for reporting the discrepancy. This was an oversight from my end. I have corrected the same in the spec.

2. If a range is specified - NuGet resolves to the lowest version specified in that range.
   E.g.

   Feed has only these versions for My.Sample.Lib: 4.0.0, 4.6.0, 5.0.0

   a. Range is specified:

   <PackageReference Include="My.Sample.Lib" Version="[4.0.0, 5.0.0]"/>

   NuGet resolves to the 4.0.0 here.

   b. Range is specified contd..

   <PackageReference Include="My.Sample.Lib" Version="[4.1.0, 5.0.0]"/>

   NuGet resolves to the 4.6.0 here.

[isaacabraham]

What happens if the NuGet.config file is on one machine but not on another, or is changed after the lock file is create - does the lock file still take effect?

[anangaur]

IMO, sources definition should not matter for a lock file. Irrespective of which source the packages are coming from, finally it should be the same package that goes into the build.

To make sure whether its the same package or not I am thinking about putting the hash of the package in the lock file. Open to other ideas.

[isaacabraham]

@anangaur Sorry, didn't explain myself very well :-) What happens in the following situation: -

1. You "turn on" repeatable builds in NuGet.config (mechanism still TBD).
2. Your team start using NuGet, lock file is generated etc.
3. Someone removes the flag in the NuGet.config.

What happens to the lock file? Does it still get used or is it discarded and deleted?

[anangaur]

@isaacabraham Haven't put much thought on it but I am leaning towards generating the file by default and not as an option.
Let me spend sometime on it and thn I will come back with the proposal.

[mletterle]

why not just have a command line option to create or consume a project wide project.assets.json file at restore time?

Something like:

nuget restore path\to\something.sln -AssetsOut something.assets.json

and later (say on a build server)

nuget restore \path\to\something.sln --AssetsIn something.assets.json

It would be up to the consumer to regenerate/edit the assets file and check it into source control and to configure their builds to use it.

This would seem to allow the requested functionality with the minimum amount of changes....

[anangaur]

Asset file is not just the restore graph but has multiple overloaded functionality and lot of contents irrelevant to a typical lock file. For example it contains all the warnings/errors applicable for the project restore. In addition to this, the assets file is not easy to understand or modify. (IMO even the lock file should not be manually edited). I have seen different assets file getting generated for the same dependencies (the lines get re-ordered) and hence it will be difficult to manage the merge conflicts. Assets file in the current form will not be able to handle floating versions.
However the current idea is very similar to generating a lock file by refactoring out the relevant contents from assets file that gets generated in the obj directory. I would rather solve this issue using a lock file mechanism than re-using the assets file and then live to support the backward compatibility in the long run :)

[mletterle]

True, just having a packages.config as input with specific, locked versions would be enough, having the ability to generate that file on restore would go a long way. packages.config is documented and presumably will be supported for the foreseeable future.