Dependencies

The dependencies attribute in 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 is a JSON object that maps a package name to a version. The version number indicates which version of the package to download from the package registry. For example:

{
  "dependencies": {
    "com.my-package": "2.3.1",
    "com.my-other-package": "1.0.1-preview.1",
       etc.
  }
}

In addition to using version numbers, the Package Manager also supports adding Project dependencies with the following:

• Embedded dependencies
• Local paths
• Git URLs

Embedded dependencies

Any package that appears under your Project’s Packages folder is embedded in that Project. Typically, when you create a new package, you embed it in your Project while you are developing it. When it is ready to be shared with other users and tested in other Projects, you can publish it to a scoped package registry.

Embedded packages do not need to appear in the Project manifest as a dependency. If they do, the package on disk takes precedence over the version of the package listed as a dependency. For example, if the Project manifest specifies a dependency on version 1.3.1 of Package X but the Project also has an embedded packageAn embedded package is a package that you store under the Packages directory at the root of a Unity Project. This differs from most packages which you download from the package server. More info
See in Glossary with that name, the Package Manager uses the embedded package, regardless of its apparent version, instead of downloading the more recent version from the registry.

It is your responsibility to track the content of your embedded packages, and any changes you make to it. If your Unity Project is under source control, you should also add packages embedded in that Project to the same source control.

Local paths

You can specify a dependency as any local directory that contains a package. This feature is helpful for local offline development and testing. To set a local path through the UI(User Interface) Allows a user to interact with your application. More info
See in Glossary, see Installing a local package.

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

You can use either absolute paths, or paths that are relative to the Project manifest root. In other words, a path preceded with two dots (..) refers to the root of the Project path (for example, <project path>/my-package).

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 an absolute path in Linux or macOS

{
  "dependencies": {
    "my_local_package": "file:/Users/johndoe/Packages/my_local_package"
  }
}

Example of an absolute path in Windows

{
  "dependencies": {
    "my_local_package":
"file:C:/Users/johndoe/Packages/my_local_package"
  } 
}

Example of a relative path

{
  "dependencies": {
    "my_local_package": "file:../test/my-test-package"
  }
}

Git URLs

When the Package Manager fetches a package from a Git repository, it adds the package locally to your Project. This allows you to easily test unpublished changes, but you cannot use it to contribute to that Git repository. To set up an existing local Git repository as a dependency in your Project, use a local path instead.

To use Git packagesThe Package Manager retrieves Git packages from a Git repository directly rather than from a package registry. Git packages 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 in a Project, make sure the Git client is installed on your machine and that you have added the Git executable path to the PATH system environment variable.

If the repository tracks files with Git LFS, make sure the Git LFS client is also installed on your machine. If it is not installed, the Package Manager can’t retrieve the files stored on the LFS server and instead checks out the LFS pointer files without any error or warning messages.

NOTE: You cannot use the Packages window to install a package directly from a Git repository. You must edit the Project manifest to add a Git URLs as a dependency.

To specify a Git URL as a dependency, add the name of the package to install with a Git URL instead of the version number or local file path. For example, this demonstrates how to specify a remote Git using the recommended HTTPS protocol:

{
        "dependencies": {
                "com.mycompany.mypackage": "https://mycompany.github.com/gitproject/com.mycompany.mypackage.git"
}

The Package Manager supports the https, http, ssh, git, and file protocols using this form:

<protocol>://[<user>[:<password>]@]<host>[:<port>]/<path>.git[#<revision>]

You can also skip the .git path suffix if the URL starts with git in these forms:

git://[<user>[:<password>]@]<host>[:<port>]/<path>[#<revision>]

or:

git+<protocol>://[<user>[:<password>]@]<host>[:<port>]/<path>[#<revision>]

You might need to configure credentials in Git configuration files in order to provide your username and password securely. This is preferable to hard-coding them in the Git URL, which is a major security issue if the Project is shared with others.

Git uses the keys at the default location when you use SSH to authenticate. However, if you are using PuTTY as the SSH client on Windows, you might need to configure the GIT_SSH environment variable to make it point to plink.exe.

You need to set up SSH keys outside of Unity. The Editor notifies you of authentication failure if you don’t have proper access.

For more information on setting up authentication for a specific host, see the help pages for GitLab and GitHub.

Targeting a specific revision

You can specify any revision to install. A revision is an expression that eventually resolves to a commit hash in Git. The most common types of revisions are commit hashes, tags, and branches.

To target a specific revision, append the following to the Git URL in the dependencies attribute: # followed by the revision (either the version or a specific Git hash). Specifying the hash ensures that you get exactly the version you want. For example:

{
    "dependencies": {
                    "com.mycompany.mypackage": "https://mycompany.github.com/gitproject/com.mycompany.mypackage.git#523c4f291cea796141e7211f4951702984d2e9ca"
        }
}

If the revision omitted, the Package Manager uses the remote repository’s HEAD revision.

For more information about setting a proper revision, see the Git user manual section on Git revisions.

Using the SSH protocol

If you want to use the ssh protocol, make sure you use the full protocol syntax. The Package Manager does not support SCP-based shorthand syntax, and many Git hosting services supply the repository’s URL with the SCP syntax. So if you are copying the URL directly, make sure you use the ssh:// protocol and replace the colon (:) before the repository path with a slash (/). For example, if you get git@mycompany.github.com:gitproject/com.mycompany.mypackage.git from a GitHub repository, make sure you change it to the full syntax, as shown in this example:

{
        "dependencies": {
                "com.mycompany.mypackage": "ssh://git@mycompany.github.com/gitproject/com.mycompany.mypackage.git"
}

NOTE: If you set up your SSH key with a passphrase, the Package Manager can’t retrieve the package, because you need to enter the passphrase in a shell or command line. In this case, consider using the https protocol instead, or use the ssh-add utility shipped with Git. For more information, see Authentication issues with Git URLs.

Using the FILE protocol

The Package Manager does not support file paths with the file prefix, but it does support full URLs with the file protocol. For example:

{
        "dependencies": {
                "com.mycompany.mypackageA": "file://localhost/absolute/path/to/com.mycompany.mypackageA.git",
                "com.mycompany.mypackageB": "file:///absolute/path/to/other/com.mycompany.mypackageB.git"
        }
}

---

• 2019–04–11 Page published with editorial review