Hey all, I’m working on a bunch of games and I decided to create a local UPM package for some of the systems I’ll be using across the games.
I created a local folder outside the game folder and created the package.json file. I then imported the empty UPM package into the project with the systems I wanted to package up. I dragged the files into the UPM Package folder.
In another project I imported the UPM package and all is well but in the original project I created the package into I can’t access the files. I tried removing the package and readding it but it’s the same. It’s like it doesn’t exist but it does, I can see it and edit the files.
I’m not sure about this process here. You should have a standalone project for each of your packages. Somewhere inside your Assets folder for said project should be the root of the package itself, which has a package.json file alongside it. Then you add said package to any other projects that need it.
Mine all use assembly definitions as well, so assembly definitions in other projects need to reference said assemblies.
Having a dedicated project for your package development workflow is an option, but I would advise against putting the package files under the Assets directory as the Package Manager will not detect them and therefore add any dependencies your package might rely on. This can lead you to create a package that is missing dependencies without you realizing it because those dependencies were declared in the project itself (so everything “checked out” until you tried the package in a separate project). It could also lead you to forget to add assembly definitions for each assembly your package needs to produce, because as long as the files are under Assets, they would be included in your project’s own assemblies and would “compile just fine” in your project, but wouldn’t be compiled when your package is used in a different project.
Instead, you should put the package under the project’s Packages folder. Alternatively, you can add it to the project’s dependencies via a “file:” dependency.
@derkoi , I’m not entirely certain I understand the problem you’re facing, but let me give you an example of what I meant above so you can try to reproduce this example. You could have the following paths:
With the above setup, you could add a file dependency from your project to the package either by using the UI (Add package from disk) or by manually adding an entry to your project’s dependencies, in C:\Unity\Projects\MyProject\Packages\manifest.json, using either examples:
The package will then show up in your project as a mutable package, which means you can drag & drop assets and scripts (don’t forget to create AsmDef assets along with the scripts) and edit properties in inspectors, etc.
I made a virtual dev drive (vhdx) to place all my packages on. It’s aptly labelled P: so all my manifest references practically have no path at all and I’m spared manually editing them. This works fine for a solo dev.
In addition, the dev drive has the added benefit that Defender is disabled on that drive, which speeds up everything. Of course I have another (bigger) dev drive labelled U: for all the Unity projects.
The only downside is that the min size is 50 gigs which the packages will never fill. But the vhdx is set to only allocate used space and expand as needed.
Thanks, I think the problem i had was not creating the assemblies. But now I have issues because my package depends on other assets. Do i need to create assemblies for those if they don’t have them?
Yes. At least I think so. I haven’t been working without asmdefs for many years.
Auto-referencing only goes the other way afaik, meaning a script not governed by an assembly definition can reference types defined in an asmdef, provided that asmdef has the auto-reference flag set. But an asmdef script can’t reference types not in an asmdef (eg anything in the default Assembly-CSharp assemblies).
I’m not sure I follow you here. It’s always worked fine for me. Though I upload my custom packages privately on github, and install them via a github URL, though it worked fine locally too. I would just point it to the package.json and then all files from that folder downwards would be included.
Any dependencies on other packages, Unity or otherwise, were handled through version defines in the assembly definition for each package. The package manager doesn’t support git hub dependencies anyway so no matter how you do it, those would fail otherwise.
I can confirm you end up with package manager not recognizing the package.json and thus not adding any of the dependencies. The whole point of a package is to have it be a unit of stuff that you can bring in with transitive dependencies being pulled in with it automatically. Any non-trivial package will break if you try to do this, version defines aren’t an option if your whole package builds upon some fundamental framework stuff like Collections / Unity Mathematics / Entities.
Right, well something for me to keep in mind in future then. It’s never been an issue for me.
And like I said, the package manager doesn’t support github dependencies (or asset store packages) which is my dependencies 99% of the time so I have to install certain packages beforehand anyway.
Okay, I just tested this. I have an internal package that has a dependency on the new Input System (added to the package.json). Installing it to a project without the Input System, either via git url or locally, adds the Input System as a dependency automatically.
This is on 2021.3 so I assume it works in later versions too.
So I don’t see the issue with my workflow. Seems more straightforward than fuddy-duddying around embedded packages or whatnot.
The only workflow I ever claimed was problematic is putting it in Assets.
Every other case is fine. That includes all the package manager ways (git, npm, disk in manifest.json) and embedding in the Packages folder. If you did any of those, I don’t dispute your result.
(I now realize I edited out a part from my first message that referred to expected ways to use the package manager, sorry that the edited message is unclear about that)
We must be referring to ‘putting it in Assets’ in different ways then. It’s only in Assets in the project I use to develop/work on the package. Otherwise when installed via either means, only the ‘Package’ part of the project (which is nested further down) gets imported as a package.
Eg:
When added to a project, only the LBG-PrototypeObjects folder and beyond get added. That’s what my initial post was referring to.
Assets is only problematic in the way the employee mentioned, developing something and carelessly leaving out necessary dependencies or asmdefs which would break stuff when importing as an actual package. It’s just a workflow that doesn’t make sense when you can just as easily develop in the Packages folder, where it’s treated as a proper package but still mutable and whatever.
If that works for you, great, it’s just not something that seems advisable / good practice for people with less experience.
Also, there are particular things like path-sensitive operations (gizmos) that wouldn’t match in Assets vs an installed / embedded package, so there’s an actual reason not to use it for package development I suppose.
Right, well that all makes sense. I honestly wasn’t aware there was another primary workflow when it came to packages until this thread. The workflow was formed from seeing how other popular packages like UniTask have their setups. Was just trying to figure out what was so heinous about it.
(Also I think I’m the person with the least experience in this thread so far)
