Custom Git Package + Assembly Definitions is not very usable when the package has dependencies

I have experimented with the custom upm packages to find out how powerful it is and while I can see that in many cases it can work, it also very quickly turns out to be a huge pain in the ass.

Let's look at this example package I setup to experiment with it:

Code (CSharp):

1. "at.noxmortem.noxlog":https://github.com/NoxMortem/NoxLog.git#77e045cdcd2f0d9b3885545aea616b2c9ec57bd1

This is a plugin which uses/supports some functionality from the Zenject IoC Plugin for Unity which is available:

• Zenject at the asset store
• Zenject on github

I added the upm package to my package.json and everything works out great so far. Now I add the scripting defines ZENJECT;LOGGING_EXTENSIONS which provide functionality which has an optional dependency to Zenject and hell gets loose.

Problems I have noticed so far:

• It is not possible to provide open source (*.cs) code as plugin without an Assembly Definition. While I in general agree on this design decision, the functionality I really am missing here is a way to easily add a dependency to ALL assembly definitions.
  • The example above is a logging framework which I now have to manually to all assemblies, as likely all of my assemblies will use this logging framework. Without using upm packages I was able to use one commonly shared asmdef, place the logger inside it and only add this commonly shared asmdef as a dependency once when setting up a project. With the current upm approach I will have to maintain these dependencies for each and every added upm and each and every asmdef with the intention to use it. Yes - I am aware that this in .NET is "normal" but for non-unity projects your IDE of choice also usually is easily able to maintain any dependencies via quick actions. To the current date I am pretty sure both Visual Studio Tools for Unity as well as the Rider Plugin for Unity are not able to detect packages/*.asmdef and update asmdef files as they could do with csproj/dll dependencies.
    
  • I have not checked for some time, but the last time I experimented with many (100+) asmdefs in a project, the editor became extremly slow (compiling, figuring out dependencies). This might be better by now, but still I am a bit worried about how robust this is with Unity when we would begin to package small functionality as shared packages in a nuget way and grow from a dozen of very restrictively created asmdefs to hundreds of asmdef by design.
  • I really wished I could just add "NoxLog.asmdef" as "inclusion" to "Commons.asmdef", which would remove the requirement to update all other *.asmdef by hand after adding "NoxLog.asmdef" and to be honest I do not even want to have to do that. Please give me a way to include a package by name as dependency, e.g. "at.noxmortem.noxlog", s.t. Commons.asmdef gets this as an "inclusion" and everything referencing "Commons.asmdef" will now have it available as well and if we stick to the requirement of providing an .asmdef for upm packages this would likely mean to require having both options: reference all .asmdef inside of a upm package or specify them individually.
• There is no way to allow "optional" dependencies. "Zenject-usage.dll" is only required if scripting define ZENJECT is set, but either I add it to the NoxLog.asmdef and require all users to also have it available or not add it and no user is able to use ZENJECT. Yes of course it is possible to split this functionality in two asmdef, one with the strict dependency to "Zenject-usage.dll" and a dependency to "NoxLog.asmdef" but this adds to an already complex dependency graph for something very simple. I really do not like how the upm/package manager/asmdef design bloats the depency graph.
• Dependencies to asset store stuff is not covered at all (at least as far as I am aware)
  
• UPM require .meta files and it will throw an error if there are none. This is annoying and I really do not want to have .meta files in a package. This becomes very stupid the second you try to generate upm packages out of non-unity .NET code which would be usable in Unity, but now you have to do like it was part of a unity project.

Code (CSharp):

1. [Error] Read only asset Packages/at.noxmortem.noxlog/LICENSE has no meta file.
2. Read only asset Packages/at.noxmortem.noxlog/package.json has no meta file.
3. Read only asset Packages/at.noxmortem.noxlog/README.md has no meta file.

So far I felt like the upm package is really more hindering me than supporting me. The requirement that a git dependency is actually a upm package is something I am also a bit on the edge with. On the one hand, yes it makes absolutely sense to only allow packaged contain to be consumed by a package manager. On the other hand I really want to specify git dependencies just as what they are: a dependency to some code in some repository. Zenject may be one day structured as upm package or not, but at this point in time I would not be able to include it as a git dependency. I likely would still need to use plain git submodules and then the problems with unity and symlinks remain (it is not that straight forward to setup as one would wish to).

Please do not read this as some sort of rant. All it is, is a set of notes I have written together after a first experiment with a new feature and the result for me was that I will for now will not use custom upm packages because they are a burden and stick to the old .unitypackage format releases as they allow me to do everything I have listed above: Specify the included folder, specify the target folder the content will go to, and therefore also solve any dependency problems as the target folder in unity determines the asmdef the code will be associated with. I just am trying to give some feedback on how to improve the upm/asmdef/(asmref)/package manager pipeline as I can see this to be the future, but sadly likely not before 2021 from what I am reading on the forum here

Also as a reminder: If the upm package itself has no dependencies or only to other unity packages most of this likely works much easier and better even today.

 

Yup, this is also something I'm concerned about. This has been brought up in various threads around the forum but it appears that this is a more complex problem that also involves work from Microsoft/Visual Studio devs.

Yup, having project-wide dependencies is something I'd also find useful, exactly for stuff like dependency injection.

Yeah, unfortunately that's not in yet and AFAIK does not have an ETA. I think it will take a while until the majority of asset store assets is accessible via UPM.

That is also the way I've been perceiving it. For now it seems to be mostly intended to be used by Unity to allow them to trim down the core engine and move most features into packages. I'm sure that will change in the future, but for now it seems that UPM for Unity users has taken the backseat for now.

Yeah, but I wonder for how many custom packages that would be the case. Basically, UPM makes custom package dependency management so inconvenient at the moment that it almost seems like it's punishing modularity. Add the issue with large-ish amounts of asmdefs above and this really doesn't look like a great way to moduralize a project's codebase for now...