Hi all,
My unity project has some local packages. specifically MRTK 3 and magic leap 2 packages added according to the the magic leap project config guide. My packages in project are the following:
naturally, I have initialized a github repo for the project but when a collaborator clones the repo and launches the project the package manager can’t find those local packages and thus can’t activate the project.
In my manifest I have noticed that some of these local packages path appear as the local path on my machine so naturally unity tries to find those packages on a path that doesn’t exist on another machine.
An example from my manifest:
So my question is How can i properly install packages from disk or tarball and still be able for other collaborators to use the project? Will a relative path will be a good solution?
regards,
Gal.
Yes, you can (and have to) manually change the paths in manifest.json to be relative.
Of course the collaborator needs to have the same packages at the same relative locations for this to work.
It’s easiest if you set up source control not to be rooted in the project’s directory but in its parent directory. That way you can have the Unity project in a subfolder and the package folders are on the same level (sibling folders).
1 Like
As @CodeSmile mentioned, the best way to make projects portable is to use relative paths (relative to the folder containing the manifest.json file, i.e. the project’s Packages folder) and use forward-slashes (/) as separators in the path, since they work on all of Windows, Mac and Linux.
The second step is to ensure that the packages are located in the same location relative to the project. That is, if you use a single repository to track the project and local packages, you can use @CodeSmile 's suggestion and nest the project one level deeper in VCS so that you have something like
/Project (project folder)
/LocalPackages (package root folder in which you store all local packages)
The above setup is compatible with Git submodules, if, for instance, you tracked the packages in their own Git repositories.
If the packages must be tracked in separate repositories and you don’t want to use Git submodules, then you can simply instruct your teammates to clone/fetch the package repositories in folders next to the project so that they locally reproduce a similar setup as above.
