Split project.lock.json into *.lock.json and *.cache.json

[Mpdreamz]

I've read this gist on checking in project.lock files a couple times over and I really feel the current locking design feels optimized for the wrong scenario: finding breaking changes in moving targets. Whereas the more important default scenario should be repeatable builds.

To the best of my understanding the current project.json.lock now serves two purposes, caching the files in play for compilation and optionally locking dependencies using --lock.

This results in a bit of a operational kerfuffle. When do i need to restore using --lock ? Do I need to unignore lock files in release tags, and if so is this not important on dev branch too? if I branch of those tags should i remove the lock file on the first change?

What if locking is simply the norm just as it is in Paket?

Restore writes a very minimal project.lock.json (look at Paket for an example) if not present that you should always commit (eradicating both --lock and lock:false confusion).

When dnx runs the app for the first time it will generate a .project.cache.json which you should never commit.

If folks want to check fast moving targets on a CI server they could do dnu restore --latest on the CI servers explicitly.

• dnu restore --latest updates all * dependencies
• dnu restore --update updates all dependencies to latest
• dnu restore --outdated simply reports on packages that are outdated

To be fair the wiki does not dictate not checking project.lock.json files but does leave it up in the air without a consistent story.

Even if we do not make locking the norm a split will really help those who do choose to commit the lock file to not be faced with merge conflicts in the cached files section of this lock file.

[muratg]

@davidfowl

[analogrelay]

Note: We need to be extremely careful what we do here now that NuGet 3 and MSBuild for UWP apps are using project.json and project.lock.json

[davidfowl]

We spoke about this today and are going to make a split. The current project.lock.json will be the generated file used for runtime/buildtime and there will be another file maybe nuget.lock.json (name is still up in the air) that will just preserve version information.

The guidance will be that nuget.lock.json should be checked in if you want to lock versions. It will not be generated by default, but you can either do dnu restore --lock or dnu lock (there will be equivalent nuget.exe commands).

There is still an open question about putting the current project.lock.json in an output directory (bin\project.lock.json or obj\project.lock.json) but this file is read by the runtime so that seems a little strange.

[forki]

So is this a way to open up for other tools like paket?

[davidfowl]

I don't want to turn this bug into a discussion about packet but the project.lock.json is basically the format that needs to be produced to make dnx apps work.

[Mpdreamz]

I'm over the moon that the split will happen.

Whats the reason for not always generating the file? I see no reason not to always generate the file and losing dnu restore --lock or dnu lock all together? The choice then becomes whether to checkin the nuget.lock.json file or not.

[davidfowl]

Because the behavior of nuget and dnu isn't changing with respect to how dependent versions are resolved. There is really no reason to lock the project in most cases and it breaks version ranges. Meaning you have to keep running commands that constant update the lock file. I agree that it is a valid workflow and there should be a way to work like that but it's not the default required flow. There are still concerns about the project.json file changing and the nuget.lock.json (or whatever we call it) being out of sync.

[Mpdreamz]

Because the behavior of nuget and dnu isn't changing with respect to how dependent versions are
resolved. There is really no reason to lock the project in most cases and it breaks version ranges.

This has absolutely nothing to do with how versions are resolved and that won't need changing either.

When I run dnu restore and commit my working version and come back 2 years later to that commit and run dnu restore it should be repeatable even with wildcard deps in place. This should totally be the default workflow that we promote.

The fact that the project file has dependency version ranges will mean that a dnu update finds updates when I ask for it explicitly. In the current state we are conflating these two responsibilities.

dnu restore

• no lock file in place? resolve all dependencies.
• lock file in place? resolve only dependencies changed in project file.

dnu update|install <id> <version>

• update or dependency to or latest

dnu outdated <id>

• return information on all or package

I'm still happy that I can now choose to atleast --lock and checkin without having to commit all of dnx's cache but I really feel conflating these two responsibilities will bite us in the long run.

[haf]

Wouldn't it be a time-saver if you replaced this with two things?

• a JSON adapter for Paket to read/write your file format
• a --nuget-versions flag in paket that means to avoid using semver and do it the nuget way instead?

An up-side of doing it this way is that @forki would single-handedly carry half of vnext on his back with bugfixes in 7 minutes. ;)

[Mpdreamz]

@haf as much as I love Paket and hope to see it being integrated with DNX in the future, your comment sets the wrong tone for the active discussion in my opinion. This ticket is to discus the merits of locking by default using dnx ootb tooling which I'm still having a hard time understanding why the aspnet team is on the fence about this.

<brainfart>With this split Paket could now detect i'm running from a vnext dir and write a much terser nuget.lock.json file instead of the entire project.lock.json. Command line integration with dnu might be out of the question but its no different then nuget at the moment.

A "restore-command" : "paket install" would be enough in global.json for tooling such as @OmniSharp to attempt paket install instead of dnu restore. </brainfart>