This is an example of what a projects manifest file might look like. It's easy to see we have a dependency on the Package Manager UI (explicitly version 1.8.0). We have also excluded the Analytics package. There could be any number of other packages included or excluded, depending on your projects precise setup and requirements.
More interestingly, we have added in our custom package, com.lms.boundingvolumes
. As we can see, all package names start with com
. The packages Unity hosts on its repository then all have .unity.
. This clearly identifies them as packages published by Unity. For our custom package, I've replaced that with .lms.
, short for LotteMakesStuff. Finally, we have the name of our actual package! In this example were packing up code that implements a Bounding Sphere structure, so we picked the name boundingvolumes
as it nicely reflects the contents of our package. (obviously, our package could contain any code - I just picked bounding volumes as I was working on them recently!).
Unlike with the package we are getting from Unity's package repository, instead of specifying a version number we want UPM to resolve, instead, we are providing a local, relative file
path to our package. File locations have to be relative. this might cause issues with code stored in version control, as we have to make sure the packages we depend on are in the same relative position on each development system. In this example, we go back two levels to the folder that contains our projects root folder and then going into a folder containing just our custom package. In a source control context, it might make more sense to host the shared content in a Unity project of its own and then have the package in a subfolder of the host projects Assets folder. this provides an easy way to test and develop our shared components and a nice way to ensure the relative paths work, all a developer has to do is ensure the shared code project is checked out side by side with the project that consumes it.
Todo
Package Manifest
The package manifest sits in the root of the folder our packages contents is stored in and provides a whole bunch of metadata to Unity describing what our package actually is. Most of this is currently used by the Package Manager UI to control how it draws our packages information, or by the Package Repository to resolve references to our package. Unfortunately, as we currently cant publish our own packages to the repository - most of it does nothing but it's still useful to make sure its set so it shows in the UI correctly. The tags that Unity currently uses are defined in the package manager documentation
Great instructions; just got it working on a test package thanks to it. Super excited about UPM. Can't wait to see people using packages for code (instead of polluting a game's code), and of course, Git support. So, thank you so much, and thanks Unity.
I'd add a few more details to make things smoother:
meta
files don't seem to be needed. In fact, Unity 2018.1 is removing them at start if I had them there.If the package location is incorrect (e.g. doesn't exist), Unity will tell you when starting the editor and loading the project.