We are getting the “DirectoryNotFoundException” on some computers for importing the com.unity.render-pipelines.high-definition package, because the path to some files in the package is too long. It seems like this could be solved if the packages used relative paths, so it wouldn’t then need to have “C:\Users\LongCorporateUserName\Documents\UnityProject” in the paths.
Unfortunately this is a more complicated question that it may seem at first glance. The package manager itself has no problem with absolute or relative paths; however, many subsystems in Unity need to use absolute paths at some point. For instance, the compiler is invoked with absolute paths, and it will fail if any is longer than the Win32 maximum path length of 260 characters (that is, drive letter + colon + backslash + 256 characters + null terminator), claiming that it cannot find the file.
We are aware of the problems long paths cause, and we are working on various improvements to shorten these generated paths. However this only delays the problem until someone uses a path prefix like “C:\Users\EvenLongerCorporateUserName\Documents\Some\Arbitrarily\Deep\File\Organization\Hierarchy\UnityProject”. (For typical users, it does make the problem much less likely.) The real fix, of course, is to identify each and every component that fails with paths that are too long, but unfortunately this turned out to be pretty difficult so far.
According to Microsoft’s documentation, the MAX_PATH restriction can be lifted for some of the Win32 APIs on sufficiently recent versions of Windows 10. In practice, you could try their fix to see if it solves the problem.
If it doesn’t, you could try setting up a directory junction (see also this page), from a short folder path to the actual path. You could achieve this with the following command (this is just an example): mklink /J "C:\UnityProject" "C:\Users\LongCorporateUserName\Documents\UnityProject" (quotes are only necessary if there are spaces in some of the folder names).