paket.local file is used for testing changes before releasing new version
of a dependent project.
- !!! This feature works only for old-style .NET projects. If will not work with .NET SDK based projects. Details here.
- You should not commit
paket.local. This file should always be added to
.gitignore, because it specifies file paths that are only accessible on your machine.
paket.localaffects only the paket restore command, not the install or update command.
- By default
paket.localwill only substitute packages with an identical version to the
paket.lockfile. See Nupkg version for alternatives.
In this tutorial you will learn how
paket.local can help you to speed up your
The Paket project uses Argu as one of its own dependencies. Argu is a library that allows to manage command line parameters:
1: 2: 3:
1: 2: 3: 4:
Let's assume that we want to contribute to Paket by adding a new feature. The new feature, however, requires a change to Argu, so we'll need to contribute to the Argu project first.
Before we create a Pull Request to Argu, we might want to test the change locally by running Paket with the applied change in the Argu package. Up until now, there was no convenient mechanism to do so, and e.g. we would manually copy updated Argu libraries to the packages directory in Paket's project after each rebuild.
paket.local file, we can improve this process, by temporarily
overriding the source for a specific package. We create a
in the root of own Paket source code copy:
The line can be translated to:
paket restoreis run, override the source of the Argu package with the source given after
Now when running
paket restore, we get the following:
1: 2: 3: 4: 5: 6: 7:
The result is:
- The build command
build.cmd NuGetis triggered for Argu on
- A new Argu NuGet package is built by this command in the
The Argu NuGet package is extracted to
packages/Argudirectory in the Paket project directory.
- Paket can be run and tested with the updated Argu library.
Note: Any override specified in
paket.local will result in a warning
restore as in the above example. This is to emphasize that we
have a local override, and the build might not be reproducible on any other
Each line in
paket.local means one override and you can have multiple
overrides at once:
The format of a
git source is the same as used in
Note: Only git repositories as NuGet source (with
Packages: ...) are
1: 2: 3: 4:
The format of the source is the same as in path sources.
Note: In the case of source overrides,
paket restore assumes that the
NuGet package already exists in the directory pointed to, no build will be
If you happen to have a
.nupkg file in a local path, but with a different
version than in
paket.lock, you can optionally specify the version which
should be used for this override. One use case might be when the package version
is determined by your build server, and
.nupkgs created locally have zero
version. This is currently supported only for source
Another use case is testing an upgraded pre-release package with an incremented version, against a consuming project. In this case you want paket in the consuming project to fetch a higher version than the paket.local file indicates.
paket.local file with version override
1: 2: 3: 4:
The dependency group can be specified with
group <group name>
nuget <package ID>. If not specified, the default group
Main is used.
All lines starting with with
# are considered comments.
Comments might prove helpful if you use
paket.local overrides on a regular
basis instead of typing the override by hand, you can just comment/uncomment