Hi guys, I have recently started using custom packages for sharing code between projects. One problem, however, is using packages on disk because Unity uses the full path and this ends up being commited to git and would either force other users to have the same path structure on their computers or change the package path by hand and remember not to commit the manifest. I have tried working with relative paths or using environment variables (as we used to in the olden days of C++), but neither seem to work.
I know there is the possibility of using packages through git, but one use case I have found that makes working with them on disk better is when I have more than one project that uses the same package and everything is being constantly developed. More specifically, I have a project to build terrains where a lot of stuff doesnāt need to be shipped, then a server and a client, all using portions of code that are separated in a ācoreā package, all of which are being developed concurrently - including the package, which I keep on disk because that allows me to develop it inside the environment of any of the projects and since itās on disk all other projects capture any changes immediately instead of having to push and refresh all 3 projects.
Is there any way of using relative or environment variables so that I can keep this set up of working with the package on disk and have it work for other users without having to change the manifest per user forcing everyone to remember not to commit the manifest?
End up in the same situationā¦ Iām thinking about creating some custom package, that will be kept in repository and that will work as an imporeter of packages I want to keep locally on each pc/mac. So you have package in repo that you add to project with url. That package would generate:
Some text file with paths to local packages you want to keep locally,
Logic for importing these packages from package json files
inside Assets folder.
After that you just need to add that text file with paths to .gitignore and there you go. Each pc/mac can have itās own local packages.
Thatās an idea, but Iām just not sure if making something that will work this way is even possible. I guess you need to have path of each local package in Packages/manifest.json to keep that āeasy editing package from project levelā feature, so you would need to update Packages/manifest.json from that custom package and then do whatever unity is doing to import packages from itās (Packages/manifest.json) content.
At the moment, you can just add that Packages/manifest.json to .gitignore and just copy/paste itās (Packages/manifest.json) content whenever you are adding, deleting or updating any other package.
Iām planning to create this package importer. I will definitely be back with some more info on this thread
I kind of understand your idea, and it could workā¦ but honestly in my opinion this should be picked up by Unity Technologies themselves, since it shouldnāt be a huge hassle for them to allow relative paths (at least) when they parse the directories.
I might not understand the issue completely, but the Package Manger does support relative paths. You just have to modify the manifest.json manually as described here: Unity - Manual: Local folder or tarball paths
Oh wow. Yeah, thatās what I was asking for. For some reason I searched the documentation and googled and searched the forum and couldnāt find this. Thanks a lot
For developing packages, the official workflow is to embed them: Embedded dependencies
This way, your manifest.json can keep referencing the canonical git or repository version of the package and only for you will the package be overridden by an editable local version.
Also note that local paths are only supported in the projectās manifest.json. Packageās own dependencies in package.json only support repository packages, no local or git packages.
Hmmm I see. That might help, but Iām not sure if it would work with my setup. I have two projects, one for a headless server and one for a client which embeds a large amount of resources, hence why I have them separately. They both reference a base package that contains the common code, so I need to be able to work on this package continuously from either project. Iāll try to set it up, but if you know anything about this please let me know. Thanks!
I have Project A with the package locally present in the Packages/ folder (called embedded package and described above by others)
I have this folder added to my git in Project A, any changes to this project goes in with Project A only
I have Project B with a junction (Windows, on Mac or Linux, you need symlink) folder pointing to the Project A/Packages/
I have this junction ignored by git (so I do not have the same thing in multiple repos)
Cons:
the shared package only gets submitted with Project A (itās minor inconvenience for me since I handle VCS from Rider, so I can keep it open anyways)
you need to remember that youāre maintaining a junction/symlink here
you need both projects checked out to work
Here is how I create one on Windows:
Obviously with Test projects and with a package I moved into the Packages folder (used the collections for demo purposes). āTestā and āTest-2021-LTSā are standard Unity projects.
Bumping this thread, hoping some Unity tech will chime in. Changing the manifest manually is a constant fight because Unity keeps reverting it to the full local path, breaking the links for all in the team from time to time, so having to manually change the manifest file every now and then. Itās a small thing, I know, but the piling up of small things becomes a huge overall burden.
