Question How does one configure Git so that the Package Manager is synced between developers?

One recurring problem I've noticed in dealing with the Package Manager is that we need to occasionally share a list of all the packages we have installed and what versions they are.

For example, my colleague installed "Riley Labrecque - Steamworks" locally through the Package Manager and pushed changes for related work.

However, on my end, because I have not repeated the installation step, I recieve compiler errors relating to the Steamworks package being absent.

In worse situations, this can lead to stuff being silently broken or bugged out on some workstations because they aren't using the same package versions. For example, another developer made a level in ProBuilder. When I pushed changes to the level containing the ProBuilder meshes, all of his meshes vanished on his worstation when he pulled my changes. It appears that the two versions of ProBuilder were fighting over how to serialize the mesh data into the scene.

It is also very tedious and error prone to ensure that all relevant packages are installed with the same versions across workstations.

Ideally, it should be the case that when someone updates or installs a package, they can push this on Git. When other developers pull, any added or updated packages will also be pulled in.

However, I'm not sure what folders should be unignored by .gitignore, or how to otherwise safely use Git to syncronize the state of the Package Manager.

Also worth noting: I moved the Post-Processing folder to the Packages folder (next to Assets) so that I could modify the post-processing shaders. I asked about this on these forums previously and this is the current workflow for package development. Ideally, packages that are moved here and the changes made to them should be synced via Git as well.

What is the currently accepted practice for doing this?

Thanks!

 

Make sure the "Packages" folder and the "manifest.json" file in it are included in source control and that no developer has a local .gitignore that excludes changes to either the "Packages" folder and its contents or the "manifest.json" file.

If that is not the case, make sure devs understand the source control merge workflow. A common issue that leads to problems you describe could be developers who rather overwrite changes to a seemingly unrelated file rather than merging changes and going through merge conflict resolution and all that.

One way you could test that is to ask every developer to add a specific (but for each a different) package to their project and then submit the changes. When they're done, sync and open the project and see whose package is missing. Check the changelist whether that dev has checked in changes, or whether someone checking in afterwards has overwritten the changes to manifest.json, or whether someone has not checked in anything or checked in "added package" but without a modified manifest.json in that changelist. Then you'll know who to talk to.

When you're done don't forget to remove those packages.

From what you report, it kind of feels crazy to think about that you even worked with these issues for I don't know how long. The package manager takes care of specifically those issues you describe - unless of course Packages/manifest.json is not shared in source control.

 

Ah, so, just make sure that:

1. .gitignore does NOT contain the folder <ProjectFolder>/Packages/ (a sibling to the Assets folder) or any of its contents, i.e. the entire packages folder is tracked.
2. Nothing related to packages within the /Library/ folder is tracked by git. (/Library/* is ignored.)

I'm not sure when it became company "wisdom" to ignore these files specifically. I know that some third party assets contain a manifest.json file, and if you import those packages, it will completely wreck your project unless you have a backup of the manifest file. (Shame on those asset store devs for including this file!)

That could have created the superstition that letting anything other than Unity's internal stuff modify this file = disaster. (Similarly to syncing your Library folder.)

I think most of our devs outgrew that phase completely within the first year of development. ;;}

To be sure, this is just a step for getting our packages synced up initially, and I shouldn't delete packages otherwise if we're already synced, correct?

The package manager has kind of gotten a bad rap among some of our team members, and long for the days of having everything dumped into Assets. Perhaps this will change everyone's opinion of using it.

 

One idea I had was to ask everyone for their manifest.json files, and manually merging them in kDiff, then sending it back to everyone to copy over. Then after all the importing magic happens, I'd commit my version, push it, they'd pull.

 

Yes to 1 and 2.

Assets with manifest breaking stuff: I guess that manifest had dependencies in it to certain packages, for instance older or newer versions of a package that you were using. That might change the installed package version and could certainly break things. But it would also be immediately obvious, unless the issues are incompatibilities rather than compile errors.

Synching the manifests is actually the easier solution than what i proposed (every dev imports a unique package).

It‘s not uncommon for superstition to make a mess of a project, or rather some part of it. There were forum posts in the past complaining about PM but for the most part it was based on incomplete understanding of package versioning and dependencies. Basically like complaining that VS 2005 has serious issues with Unity 2022.

You got to have everything synched up to some degree, and sometimes this means updating your own code due to API changes or not using an assets that‘s too old ans hasn‘t been updated for a long time (I always check last release date and if that is > 1 year for a code asset I get cautious).

PM is certainly leaps and bounds ahead of the old ways of integrating assets: dumping them all into Assets/ and possibly even without any .asmdef. Essentially that was hoping for the best. Initial PM certainly had issues too but as things progress you hve to revisit them from time to time. Fighting superstition in a team is really important and it helps to have someone on a team who keeps checking out the latest stuff, although you sometimes have to slow them down (no, we won‘t import that cool v0.1 preview alpha package ).