Local folder or tarball paths

You can specify a dependencyIn the context of the Package Manager, a dependency is a specific package version (expressed in the form package_name@package_version) that a project or another package requires in order to work. Projects and packages use the dependencies attribute in their manifests to define the set of packages they require. For projects, these are considered direct dependencies; for packages, these are indirect, or transitive, dependencies. More info
See in Glossary as any local folder or tarball that contains a package. This feature is helpful for local offline development and testing.

Note: If you want to reference a package on the local file system as a Git dependency, use the file://<url> format instead. Unity does not support directly referencing a locally-accessible Git repository with a file path. For more information on the file://<url> format, see Git dependenciesThe Package Manager retrieves Git dependencies from a Git repository directly rather than from a package registry. Git dependencies use a Git URL reference instead of a version, and there’s no guarantee about the package quality, stability, validity, or even whether the version stated in its package.json file respects Semantic Versioning rules with regards to officially published releases of this package. More info
See in Glossary.

This section describes how to use the project manifestEach Unity project has a project manifest, which acts as an entry point for the Package Manager. This file must be available in the <project>/Packages directory. The Package Manager uses it to configure many things, including a list of dependencies for that project, as well as any package repository to query for packages. More info
See in Glossary to set up a local dependency. If you want to use the Package Manager window instead, follow the instructions on these pages:

• Installing a package from a local folder
• Installing a package from a local tarball file

The path reference always begins with the file: prefix, and uses forward slashes (/) for path separators.

Note: On Windows, you can also use backslashes (\), but only if you escape each one (for example, "file:..\\github\\my_package_folder" or "file:C:\\Users\\my_username\\github\\my_package_folder"). These paths are not as easy to read as the forward slashes, they are prone to typing errors, and you can’t use them anywhere but on a Windows machine. For these reasons, using forward slashes is preferable.

You can use either absolute paths, or paths that are relative to the project’s Packages folder (that is, the root folder of the project manifest). In other words, a path preceded with two dots (..) refers to the root of the project path, so that ../another_folder is a sibling of the Packages folder.

Tip: Relative paths with forward-slashes provide better portability across different machines and operating systems when tracking a project and packages in the same repository.

For Windows absolute paths, the drive letter and its colon (usually C:) follows the file: prefix but is otherwise identical to Linux or macOS paths.

Example of a relative path

After the file: prefix, the path is a standard relative path:

{
  "dependencies": {
    "my_package_a": "file:../github/my_package_folder",
    "my_package_b": "file:../Downloads/my_package_tarball.tgz"
  }
}

Example of an absolute path in Linux or macOS

After the file: prefix, the path is a standard POSIX path, starting with a forward slash /:

{
  "dependencies": {
    "my_package_a": "file:/Users/my_username/github/my_package_folder",
    "my_package_b": "file:/Users/my_username/Downloads/my_package_tarball.tgz"
  }
}

Example of an absolute path in Windows

Notice that the drive letter immediately follows the file: prefix:

{
  "dependencies": {
    "my_package_a": "file:C:/Users/my_username/github/my_package_folder",
    "my_package_b": "file:C:/Users/my_username/Downloads/my_package_tarball.tgz"
  }
}