Hey. Since we’re working more and more extensively with the UPM, I wonder how duplicate GUIDs are resolved when importing multiple packages (especially our own)?
As no script will be loaded when there is no .meta file found for it, each file needs a .meta file for it containing its GUID for referencing. When an asset is created in my Unity project, the meta file is automatically created and an unique GUID is added to it.
But what if I import now a package with a script which has the same GUID?
And what happens if I import two packages (from git repositories) which each contain an asset with the same GUID and I can’t change that manually (as I can’t write to git repos)?
assets with the same GUID will conflict, regardless if they are in Assets/ or Packages/.
if they are in Assets/ or a local/embedded (writable) package, Unity will generate a new GUID for one of them. all references to it will silently break.
if both of them are in non-writable packages, Unity can’t do anything, so I think it will refuse to import one of them and give an error.
then you either embed the package, have Unity change the GUID and fix all the references, or contact the package maintainer for a fix
that said, a GUID is a random string with 128 bit of entropy, chances of a collision between unrelated assets are 1/2^64 ~= 0.0000000000000000005421%.
a GUID collision is probably a sign that an asset has been copied inside 2 different packages instead of using dependencies
Not good, but expected. So if something breaks after a package import, this may be the reason.
Also not good.
In our case we’re currently developing some part of our code base in a package, hosted on a git repository. As the editor can’t write to that repository, we need to create .meta files by ourself. Now comes the question: which GUIDs are free in our project(s)? We need to generate now GUIDs for our package scripts which are not used by any of our projects and any package provider.
So though I agree the chance is pretty small, it increases with the number of packages we import, the number of projects we’re using our package in and the number of scripts we have in our package.
So I wonder how the workflow is on Unity side (the provider of most of the packages atm) to ensure this.
The idea behind GUIDs is that you just generate them semi-randomly and you rely on the extremely low chance of collisions, instead of actually checking if the GUID is in use. I’d recommend to use an existing GUID generation library to make sure the generation is robust (e.g. .Net’s built-in Guid.NewGuid).
But I think you’re missing the bigger picture here: To actually develop a package, you want the package to be embedded or local, in which case the package becomes editable in Unity. This lets you test the package properly and Unity will create all the necessary meta files you. Check the Unity documentation on creating packages for more info.
Well, I’m aware of that. I would really love to avoid creating my library as a package and just use generated DLLs from the packages I need. But I described here why this is not possible at the moment and I consider this structure currently as “to be changed” as soon as Unity will provide a solution to this problem.
This brought me to investigate the system more though and made me think about the GUID problematic. Thanks for the link, this may help us in the meantime and I really hope Unity will improve the compilation process of the packages. Maybe a solution would be to get rid of the monolithic Unity libraries, as these are mostly what are causing the problem in the first place!?