1.md
**UPM: How to make a custom package**
So, Unity has this shiny new package manager, and you have code you want to share between projects - wouldn't it be great if we could bundle up our shared code and plug it into all the projects that need it? Let's figure out how to make our own Package!
---
`Todo`
- [ ] Modify the project manifest
- [ ] Make a package manifest
- [ ] Package the manifest up with some test code
- [ ] Try it out in Unity!
---
This file has been truncated. show original
2-example-manifest.json
{
"dependencies": {
"com.unity.package-manager-ui": "1.8.0",
"com.unity.analytics": "exclude",
"com.lms.boundingvolumes": "file:../../CustomPackageTest/lmsBoundingVolumes"
}
}
3.md
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`
- [x] Modify the project manifest
- [ ] Make a package manifest
- [ ] Package the manifest up with some test code
This file has been truncated. show original
There are more than three files. show original
