When you work in the Package Manager window, you can install packages from several sources (a registry, a local folder or tarball, and a Git URL). However, while the Package Manager installs packages from these sources seamlessly, it first has to make a series of calculations to decide which version to install, and which other packages and versions to install to support it.
When you select a package version to install through the Package Manager window, you are adding a dependency to your 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. This is a declaration that you need a specific version of a particular package in order for the project to work. Dependencies that appear in your project manifest are called “direct” dependencies.
Packages can also require other packages in order to work. These are called “indirect”, or transitive, dependencies. The package developer adds these dependencies to the package’s manifest during development. For example, in the diagram below, the alembic@1.0.7
package has a dependency on the timeline@1.0.0
package, so the timeline package is an “indirect ”dependency. On the other hand, the project has dependencies on the cinemachine@2.6.0
and alembic@1.0.7
packages, so those are both “direct” dependencies.
When you add a package version as a dependency, that version is not necessarily the version that the Package Manager installs, because it has to consider all of the dependencies in your project, whether direct or indirect. For example, in this case, the Settings Manager package requested was version 1.0.1, but the installed version is actually version 1.0.3 because another package depended on the higher version, as indicated in the information message (B):
The Package Manager can only install one package version at a time, so it has to construct a dependency graph, which is a list of every direct and indirect dependency for the project. The dependency graph determines which version of each package to install.
When the Package Manager successfully resolves all version conflicts, it saves the resolution in a lock file to ensure determinism (so that the same packages are reliably installed every time), and to reduce the amount of time and resources it takes to compute the dependency graph again.