Question What's the process for maintaining/updating a unity package?

Say I create a unity project. Let's call it "MyAwesomeGame", and inside the MyAwesomeGame project I've implemented something that I want to create a reusable package out of to be used as a utility in other games and apps. Say I call it "MyPackage". Now let's say that I import MyPackage into other games and apps on the same machine.

What's the process of maintaining and updating MyPackage now? I wouldn't think that it makes sense to keep using the original "MyAwesomeGame" unity project to do updates to this MyPackage right? Would the intended workflow be to use this initial project to create the functionality, export this to a dedicated project, put it on a gitlab repo, then delete MyPackage completely from the MyAwesomeGame, and reimport from the package manager with the github url, and only make changes to the package in the future on the dedicated project you made for package updates/changes?

I should mention that my confusion mainly lies in the fact that if I make a change to MyPackage in one of the many consuming projects that MyPackage now exists in, and I want that change to be able to updated in the other host projects, I would either need all of these package sub-folders to be a git repo pointing to the same place, so that I could push changes from any of them, or I would need to make an authoritative local project where I do all my changes to the package, presumably after already implementing the change in one of the host projects when I noticed the bug/conceived the feature. Neither of these options really feel right to me.

Basically, if I have this package in multiple local projects, where am I updating/maintaining the package?

 

It’s not a bad idea to put the entire development project for the project in source control. That would help get anyone else up to speed if you were to share the package, and generally provides a consistent environment. The git url would need to use the

path

URL query parameter, like

git_url.git?path=/Packages/com.mytech.mypackage

. Unity’s Input System repo is an example of this.
It’s also good to specify a specific commit when referencing the repo, and update this in your consuming projects when you push a stable version of the package.
https://docs.unity3d.com/Manual/upm-git.html#syntax

 

This is my workflow:

• each package in its own repository
• packages cloned locally to stable location (P:/***)
• use "import from disk" in target project(s)

The "import from disk" strategy leaves the package writeable in all projects. I strive to keep them working in all projects. If I ever found the need to keep a package version stable for a given project, I would either embedd the desired version into the project, or I would clone a specific branch/commit to a separate folder and import this.

 

That's interesting information. I didn't know about the path parameter. However, I'm not totally sure you explicitly answered my question; are you saying the answer to my question is that you would make a dedicated project for the package where you would do all future maintenance/updates? Was that what you meant by "development project"?

 

Sorry if I missed this or didn't understand, but when you decide to make a change to the package that you might potentially want to propagate to the consuming projects, where are you making the change? Do you have a dedicated Unity project for implementing package changes, then pushing from there?

 

If you primarily develop the package by working on it from inside active projects that aren’t just used for developing that package, the package’s development repo could just be the package itself, and your active project could use the package’s repo as a git submodule / plastic scm xlink.

If you want to primarily work on the package on its own outside the context of a real project or want to share the package, I would include a full development project in the package’s repo for ease of setup of a development environment. It’s not a technical necessity, just a convenience for a common work area and maybe some scripts / assets in the project to experiment with features or maybe add to the package later as samples.

If there are interdependent packages you want to work on at the same time, I would revert to having the repos be only the packages, and instead use git submodules / plastic scm xlinks to each in a development project, shared or not.

Updating references to repos that use git URLs is always going to be annoying. If you have a package from git in a project, you can only update it by updating the tag / commit in the project’s manifest. It gets bad for having multiple git packages in a project, the versions of dependencies in each project’s package.json mean nothing because A) they can only refer to raw package versions and B) git references are the only way to actually get the package version you want. Using git submodules to link to each package with a filepath instead, you could just pull the development branches of each package if you want. If you eventually publish packages somewhere like a private NPM registry you host yourself or something like the artifact services offered by GitHub / GitLab, you would be able to keep references in projects simple, but of course that brings in the work and responsibility to set up releases instead of using your incremental work arbitrarily. Making releases is ideal if you’re not tightly linking developing the package with working on an actual project. If not, I would link to submodules if the real project is already a git repo, otherwise I would just bear with the explicit package manager manifest git URLs.

 

I simply work in the project I currently focus on. When I switch to other projects sure I might find I accidentally broke something but that's typically easy to fix. Part of my strategy is to work with rather fine-grained set of packages, basically how one would typically use an Assembly Definition is a package. Here are most of them (some are private).

Of course I would apply more rigor and discipline if these individual projects had "more weight" by cloning packages used by a project into sibling folders next to the project. But managing this many repositories is a big headache.